Identifying denial-of-service attacks

ABSTRACT

A computer-implemented method of identifying a denial-of-service attack during a threshold signature scheme, wherein each participant has respective shares of first and second shared secrets, wherein the method is performed by a first participant of the group and comprises: calculating a first target share; calculating a target value based on the first target share and a first predetermined amount of other target shares; calculating a target public key corresponding to the target value; calculating a first verification share based on the first share of the first shared secret and a public key corresponding to the second shared secret; calculating a verification public key based on at least the first verification share and a second predetermined amount of other verification shares; and determining whether at least one other participant is attempting a denial-of-service attack based on whether the verification public key matches the target public key.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is the U.S. National Stage of International ApplicationNo. PCT/EP2021/076686 filed on Sep. 28, 2021, which claims the benefitof United Kingdom Patent Application No. 2017103.9, filed on Oct. 28,2020, the contents of which are incorporated herein by reference intheir entireties.

TECHNICAL FIELD

The present disclosure relates to a method of identifying adenial-of-service attack during a threshold signature scheme.

BACKGROUND

Public-key cryptography is a type of cryptographic system that usespairs of keys: private keys which are known only to the owner of theprivate key, and public keys which are generated based on thecorresponding private key and which may be disseminated withoutcompromising the security of the private key.

Public-key cryptography enables a sender to encrypt a message using arecipient's public key (i.e. the public key corresponding to a privatekey known only to the recipient). The encrypted message can then only bedecrypted using the recipient's private key.

Similarly, a sender can use their own private key to sign a message,e.g. to prove that the message is being sent by the sender, and/or toindicate that the sender agrees with the message. The signer (i.e. theparty generating the signature) uses their private key to create adigital signature on the message. Anyone with the signer's correspondingpublic key can use the same message and the digital signature on themessage to verify whether the signature was validly created, i.e.whether the signature was indeed made using the signer's private key.

A digital signature scheme typically involves three procedures, i.e.algorithms. A key generation algorithm is used to generate a randomprivate key and a corresponding public key. A signing algorithm is usedto generate a signature based on a message and the private key. Averification algorithm is used to verify, given a public key and themessage, whether the signature has been generated using thecorresponding private key and according to the signing algorithm.

A threshold signature scheme allows a threshold number of participantsin a group to create a digital signature on (or of) a message usingindividual shares of a shared private key. Here, a digital signature isa signature which is generated based on the message to be signed. Insuch a scheme, the signature can only be created if the threshold numberof participants agree to generate the signature on the message. Anyattempt to generate a signature using a smaller number of participantswill not generate a valid signature. Therefore, a valid signature by thegroup (i.e. one generated using the message and the shared private key)provably had the threshold number of people agree to generate thesignature. This also implies that any adversary needs to obtain thethreshold number of shares of the private key to forge a signature withthat private key.

A common feature of threshold signature shares is that if any of theprivate key shares are lost, the private key can still be recoverableprovided that the threshold number of shares are still available.

One particular digital signature algorithm is the Elliptic Curve DigitalSignature Algorithm (ECDSA). There are two common threshold schemes forECDSA signature. One threshold ECDSA scheme is a non-optimal schemewhere a group collectively own a shared private key with a threshold oft+1, but creating a signature requires a higher threshold of 2t+1. For adetailed description see Gennaro, R, et al., “Robust threshold DSSsignatures”, International Conference on the Theory and Applications ofCryptographic Techniques, Springer, Berlin, Heidelberg, 1996. Thisscheme is referred to below as the “non-optimal Gennaro scheme”.

The other common threshold ECDSA scheme is an optimal scheme, whereoptimal means that the threshold to create a signature is the same asthat of the shared private key. For a detailed description see Gennaro,R, and Goldfeder, S., “Fast multiparty threshold ECDSA with fasttrustless setup”, Proceedings of the 2018 ACM SIGSAC Conference onComputer and Communications Security, 2018. This scheme is referred tobelow as the “optimal Gennaro scheme”.

SUMMARY

A third threshold ECDSA scheme was developed by Pettit, M and isdescribed in GB2005953.1. It has the computational, storage, andcommunication advantages of the non-optimal Gennaro scheme, whilstcrucially being threshold optimal, like the optimal Gennaro scheme. Thedetails of this scheme are provided below.

Each of the three threshold signature schemes mentioned above (andthreshold signature schemes in general) rely on the participation of atleast some of a group of participants. A valid signature can only begenerated if at least some of the group (i.e. a threshold number) ofparticipants provides a valid signature share. If one or moreparticipants provide an invalid (i.e. incorrectly calculated) signatureshare, then the resulting signature will also be invalid. A signaturemay be invalid in that it cannot be verified using a public keycorresponding to the shared private key.

As part of calculating a respective signature share, each participantmust use data provided by the other participants. Therefore a maliciousparticipant of the group can choose to provide incorrect data in orderto prevent one or more participants from calculating a respective validsignature share. In particular, a malicious participant may set upshared secrets (e.g. shared private keys) correctly and then sendincorrect data that will result in incorrect values used in thesignature. Previously, this would only be caught when an incorrectsignature is calculated.

Depending on the use case, an invalid signature can have severedetrimental effects. In general, an invalid signature cannot be verifiedand thus a verifying party cannot verify that the signature generatingparty is the party who did indeed generate the signature. In the contextof the blockchain, a valid signature is normally required to assign(e.g. spend) an unspent transaction output (UTXO) of a blockchaintransaction. Therefore the UTXO cannot be assigned without a validsignature. As another example, a valid signature may be required inorder to perform a vote, or similar events that requiring a certainnumber of participants to take action. Therefore a malicious party mayprevent a vote from happening by denying the calculation of a validsignature.

In general, a malicious party may perform a denial-of-service attack bypreventing a valid signature from being generated. It would therefore bedesirable to be able to identify such denial-of-service attacks in orderto the generation of invalid signatures in the first place.

According to one aspect disclosed herein, there is provided acomputer-implemented method of identifying a denial-of-service attackduring a threshold signature scheme, wherein each participant of a groupof participants has a respective share of a first shared secret and arespective share of a second shared secret, wherein the method isperformed by a first participant of the group and comprises: calculatinga first target share based on at least a first share of the first sharedsecret and a first share of the second shared secret, wherein the firsttarget share is used to calculate a first signature share of a thresholdsignature; calculating a target value based on the first target shareand a first predetermined amount of other target shares, wherein eachother target share is calculated by a respective participant;calculating a target public key corresponding to the target value;calculating a first verification share based on the first share of thefirst shared secret and a public key corresponding to the second sharedsecret; calculating a verification public key based on at least thefirst verification share and a second predetermined amount of otherverification shares, wherein each other verification share is calculatedby a respective participant; and determining whether at least one otherparticipant is attempting a denial-of-service attack based on whetherthe verification public key matches the target public key.

If all participants are honest and have calculated their respectivetarget shares correctly, then the verification public key should match(i.e. be equal to) to the target public key. If at least one participantis dishonest and has calculated an incorrect target share, then theverification public key and the target public key will not match.Therefore the honest participant(s) can identify an attempteddenial-of-service attack and choose not to proceed further in thesignature calculation using the target shares. This means that aninvalid signature will not be calculated, this preventing negativeconsequences, e.g. those discussed above.

According to another aspect disclosed herein, there is provided acomputer-implemented method of identifying a denial-of-service attackduring a threshold signature scheme, wherein each participant of a groupof participants has a respective share of a shared private key, arespective share of an ephemeral private key, a respective share of afirst blinding key, and a respective share of a second blinding key,wherein the method is performed by a first participant of the group andcomprises: calculating a first public key corresponding to a firstinverse ephemeral private key share, wherein first public key iscalculated based on i) an inverse of a product of the ephemeral privatekey and the first blinding key, and ii) a public key corresponding to afirst share of the first blinding key; calculating a second public keycorresponding to a pre-signature share, wherein the second public key iscalculated based on i) a public key corresponding to an intermediaryvalue and ii) a public key corresponding to a first share of the secondblinding key, wherein the intermediary value is based on i) an inverseof the ephemeral private key, ii) the private key and iii) the secondblinding key; and sending the first public key and the second public keyto a coordinating party, wherein the coordinating party has access to afirst signature share calculated by the first participant, and whereinthe first signature share is calculated based on i) a first share of theephemeral private key, ii) a message, iii) a public key corresponding tothe shared private key, and iv) a first share of the second blindingkey.

According to another aspect disclosed herein, there is provided acomputer-implemented method of identifying a denial-of-service attack,wherein each participant of a group of participants has a respectiveshare of a private key, a respective share of an ephemeral private key,a respective share of a first blinding key, and a respective share of asecond blinding key, and wherein the method is performed by acoordinating party configured to generate a signature based on athreshold number of signature shares, and comprises: receiving a firstpublic key from a first participant; receiving a second public key fromthe first participant; receiving a first signature share from the firstparticipant; calculating a public key corresponding to a first candidatesignature share based on i) the first public key, ii) a message, iii) apublic key corresponding to the shared ephemeral private key, and iv)the second public key; and determining whether the first participant isattempting a denial-of-service attack based on whether a public keycorresponding to the first signature share matches the public keycorresponding to the first candidate signature share.

According to another aspect disclosed herein, there is provided acomputer-implemented method of identifying a denial-of-service attack,wherein each participant of a group of participants has a respectiveshare of a private key, a respective share of an ephemeral private key,a respective share of a first blinding key, and a respective share of asecond blinding key, and wherein the method is performed by acoordinating party configured to generate a signature based on athreshold number of signature shares, and comprises: calculating a firstpublic key corresponding to a first inverse ephemeral private key shareof a first participant; calculating a second public key corresponding toa pre-signature share of the first participant; receiving a firstsignature share from the first participant; calculating a public keycorresponding to a candidate first signature share based on i) the firstpublic key, ii) a message, iii) a public key corresponding to the sharedephemeral private key, and iv) the second public key; and determiningwhether the first participant is attempting a denial-of-service attackbased on whether a public key corresponding to the first signature sharematches the public key corresponding to the candidate first signatureshare.

BRIEF DESCRIPTION OF THE DRAWINGS

To assist understanding of embodiments of the present disclosure and toshow how such embodiments may be put into effect, reference is made, byway of example only, to the accompanying drawings in which:

FIG. 1 schematically illustrates an example system for generating asignature of a message according to embodiments of the presentinvention,

FIG. 2 schematically illustrates an example method for generating asignature share of a message according to embodiments of the presentinvention, and

FIG. 3 schematically illustrates an example blockchain transactionprotocol.

DETAILED DESCRIPTION OF EMBODIMENTS Cryptographic Preliminaries EllipticCurve Groups

An elliptic curve E satisfies the equation:

y ² =x ³ +ax+b mod p

where a, b∈

_(p) and a, b are constants satisfying 4a³+27b²≠0. The group over thiselliptic curve is defined to be the set of elements (x, y) satisfyingthis equation along with the point at infinity

, which is the identity element. The group operation on the elements inthis group is called elliptic curve point addition and denoted by +.This group is denoted by E(

_(p)) and its order by n.

This group operation can be used to define another operation on theelements called point multiplication denoted by ·. For a point G∈E(

_(p)) and a scalar k∈

_(n)*, the point k·G is defined to be the point G added to itself ktimes.

In elliptic curve cryptography, a private key is defined to be a scalark∈

_(n)\{0} where

_(n)\{0} is notation for the set {1, . . . , n−1}, and the correspondingpublic key is the point k·G on an elliptic curve. For instance, in someblockchain protocols, the elliptic curve is chosen to be the secp256k1elliptic curve, and the values a, b, and p are completely specified bythis curve. The order n of this group has been calculated given thesevalues, which in the case of this curve is a prime, and the secp256k1standard also specifies a point G which is to be used as the generatorof this group.

Elliptic Curve Digital Signature Algorithm

In order to create a signature on a message msg, with the private key a,the following steps are taken:

-   -   1. Calculate the message digest e=hash(msg), where may be any        hash function. For instance, in some examples        hash(msg)=SHA256(SHA256(msg)) where SHA256(▪) is the SHA-256        hash function. Note that instead the message may be hashed only        once, or more that two times with the same or different hash        functions.    -   2. Chose a random integer k∈{1, . . . , n−1}, where n is the        order of the elliptic curve, e.g. the secp256k1 curve. In the        following, k is referred to as the ephemeral private key.    -   3. Calculate the ephemeral public key corresponding to this        ephemeral private key k·G=(R_(x), R_(y)).    -   4. Calculate r=R_(x) mod n. If r=0, return to step 2.    -   5. Calculate the multiplicative inverse of the ephemeral key k⁻¹        mod n.    -   6. Calculate s=k⁻¹(e+ar) mod n. If s=0, return to step 2.    -   7. The signature on the message msg is (r, s).

The ephemeral key must be kept secret, otherwise the private key can becalculated, given a message and signature. Additionally, each time asignature is generated, a different ephemeral key must be used. If thisis not the case, it is possible to derive the private key a given twodifferent signatures and their corresponding messages.

Given a message msg, a public key P=a·G, and corresponding signature (r,s), then one can verify the signature by completing the following steps:

-   -   1. Calculate the message digest e=hash(msg), e.g.        e=SHA256(SHA256(msg)).    -   2. Calculate the multiplicative inverse s⁻¹ of s modulo n.    -   3. Calculate j₁=es⁻¹ mod n and j₂=rs⁻¹ mod n.    -   4. Calculate the point Q=j₁·G+j₂·P.    -   5. If Q=        , the point at infinity, the signature is invalid.    -   6. If Q≠        , then let Q:=(Q_(x), Q_(y)), and calculate u=Q_(x) mod n. If        u=r, the signature is valid.

In threshold signature schemes, this private key a is split into keyshares that are distributed amongst participants in a threshold schemegroup.

Joint Verifiable Random Secret Sharing

Assume that N participants want to create a joint secret that can onlybe regenerated by at least (t+1) of the participants in the scheme. Tocreate the shared secret, the following steps are taken:

-   -   1. The participants agree on the unique label i for each        participant. Each participant i generates (t+1) random numbers

a _(ij)∈_(R)

_(n)\{0}, ∀j=0, . . . , t,

-   -   where ∈_(R) means a randomly generated element of the set        _(n)\{0} where        _(n)\{0} is notation for the set {1, . . . , n−1}. Then each        participant has a secret polynomial of order t

f _(i)(x)=a _(i0) +a _(i1) x+ . . . +a _(it) x ^(t) mod n,

-   -   for i=1, . . . , N. Note that we omit the mod n notation from        now on, and it is assumed that all arithmetic operations over        integers are done modulo n.    -   2. Each participant i sends the value f_(i)(j) to participant j        e.g. using a secure communication channel with participant j        only.    -   3. Each participant i calculates their own private secret share        of a shared secret polynomial as

$a_{i}:={\sum\limits_{j = 1}^{N}{{f_{j}(i)}.}}$

A shared secret share is a point with the form (i, a_(i)), where i isthe participants label in the scheme. This method for creating a secretshare of a, as described in steps 1-3, is denoted herein bya_(i)=JVRSS(i) for participant i. Note that “JVRSS” typically stands for“Joint verification random secret sharing” and includes steps 4 and 5 aswell. However, throughout this document JVRSS is taken to meanperforming at least steps 1 to 3, where steps 4 and 5 are optionalsteps.

Now that the participants have generated a shared polynomial, they caneach verify that the other participants have shared the correctinformation to all participants, and that all participants have the sameshared polynomial. This is done in the following way.

-   -   4. Each participant i broadcasts to all participants the        obfuscated coefficients

a_(ik)·G,

-   -   for k=0, . . . , t.    -   5. Each participant i checks that each participant j has        correctly calculated the polynomial point f_(j)(i) by        calculating f_(j)(i)·G and verifying that

${{f_{j}(i)} \cdot G}\overset{?}{=}{\sum\limits_{k = 0}^{t}{i^{k}\left( {a_{jk} \cdot G} \right)}}$∀j = 1, …, N.

If all participants find that this equation holds for each polynomial,then the group can collectively be sure that they have all created thesame shared polynomial.

Reconstructing a Shared Secret

Assume a participant wants to reconstruct a shared secret a which is thezeroth order of a shared polynomial. Given (t+1) points on thispolynomial of the form

(1,a ₁), . . . , ((t+1),a _(t+1)),

then to find the shared secret a, one calculates

${{{interpolate}\left( {a_{1},\ldots,a_{t + 1}} \right)} = {\left( {\sum\limits_{l = 1}^{t + 1}{a_{l}{\prod\limits_{\underset{j \neq l}{{1 \leq j \leq {({t + 1})}},}}{\left( {- j} \right)\left( {l - j} \right)^{- 1}}}}} \right) = a}},$

which is derived from a general formula known as “LagrangeInterpolation”.

Public Key Calculation

Given the N zeroth-order private polynomial coefficient public keysa_(i0)·G for i=1, . . . , N shared in step 4 of JVRSS, each participantcalculates the shared public key P using

${P = {{a \cdot G} = {\sum\limits_{j = 1}^{N}{a_{j0} \cdot G}}}},$

corresponding to the shared secret a.

Addition of Shared Secrets

To calculate the addition of two shared secrets that are shared amongsta group of N participants, where each secret polynomial has order t,without any entity knowing the individual secrets, the following stepsare taken:

-   -   1. Generate the first shared secret a, where participant i's        share is given by a_(i)=JVRSS(i) for i=1, . . . , N with a        threshold of (t+1).    -   2. Generate the second shared secret b, where participant i's        share is given by b_(i)=JVRSS(i), with a threshold of (t+1).    -   3. Each participant i calculates their own additive share

v _(i) =a _(i) +b _(i) mod n.

-   -   4. All participants broadcast their additive share v_(i) to all        other participants.    -   5. Each participant interpolates over at least (t+1) of the        shares v_(i) to calculate

v=interpolate(v ₁ , . . . , v _(t+1))=a+b.

This method for the addition of shared secrets is denoted by ADDSS(i)for participant i, which results in each participant i knowing v=(a+b).

Product of Shared Secrets

To calculate the product of two shared secrets that are both sharedamongst a group of N participants, where each secret polynomial hasorder t, the group takes the following steps:

-   -   1. Generate the first shared secret a, where participant i's        share is given by a_(i)=JVRSS(i) for i=1, . . . , N. The shared        secret polynomial has order t, meaning (t+1) participants are        required to recreate it.    -   2. Generate the second shared secret b, where participant i's        share is given by b_(i)=JVRSS(i), and the shared secret        polynomial again has order t.    -   3. Each participant calculates their own multiplicative share        μ_(i) using

μ_(i)=a_(i)b_(i).

-   -   4. All participants broadcast their multiplicative share μ_(i)        to all other participants.    -   5. Each participant interpolates over at least (2t+1) of the        shares μ_(i) at 0 to calculate

μ=interpolate(μ₁, . . . , μ_(2t+1))=ab.

This method for calculating the product of two shared secrets is denotedherein by μ=ab=PROSS(i) for participant i.

Inverse of a Shared Secret

In order to calculate the inverse of a shared secret a, the followingsteps are taken:

-   -   1. All participants calculate the product of shared secrets        PROSS(i), the result of which is μ=ab mod n.    -   2. Each participant calculates the modular inverse of μ which        results in

μ⁻¹=(ab)⁻¹ mod n.

-   -   3. Each participant i calculates their own inverse secret share        by calculating

a_(i) ⁻¹=μ⁻¹b_(i).

This method for calculating the inverse of shared secrets is denoted bya_(i) ⁻¹=INVSS(i) for participant i.

Shared Private Key Generation and Verification

To calculate a shared private key a between N≥2t+1 participants, t+1 ofwhich are required to create a signature, the participants execute JVRSSwith a threshold of t+1 and public key calculation as described above.The result is that every participant i=1, . . . , N has a private keyshare a_(i) and the corresponding shared public key P=(a·G).

Ephemeral Key Shares Generation

To generate ephemeral key shares and the corresponding r, as is requiredin a signature, a group of size N with a shared private key a ofthreshold (t+1) execute the following steps:

-   -   1. Generate the inverse share of a shared secret k_(i)        ⁻¹=INVSS(i), where (t+1) shares are required to recreate it.    -   2. Each participant calculates

${\left( {x,y} \right) = {\sum\limits_{i = 1}^{N}\left( {k_{i0} \cdot G} \right)}},$

-   -   using the obfuscated coefficients shared in the verification of        k_(i), then they calculate

r=x mod n.

-   -   3. Each participant i stores (r, k_(i) ⁻¹).

Identifying Denial of Service Attacks

Embodiments of the present invention enable denial-of-service attacks inthe context of threshold signatures to be identified. FIG. 1 illustratesan example system 100 for generating a threshold signature. A completedescription of one example signature scheme is provided below under theheading “Threshold Optimal Signatures”. Embodiments of the presentinvention will be described with reference to FIG. 1 , but it will beappreciated that the embodiments apply equally to other signatureschemes, e.g. the Gennaro schemes mentioned above.

In general, each participant 102 of a group has a respective share of ashared private key which is used to generate a respective share of asignature. Each participant also has respective shares of one or morefurther shared secrets. For instance, each participant 102 has arespective share of an ephemeral private key and a respective share of ablinding private key. A blinding private key is used to obfuscate adifferent private key. In some examples, each participant 102 may alsohave a respective share of a second blinding private key.

As part of a threshold signature scheme, each participant 102 isgenerally required to share data with and obtain data from the otherparticipants in the group for further calculation. Embodiments of thepresent invention may be used to determine whether the obtained data hasbeen calculated correctly, and therefore whether the obtained data canbe used to calculate a signature share.

The shared data that is required as part of the calculation of arespective signature share will be referred to as a “target share”. Thatis, each participant 102 that generates a signature share requires atarget share from each other participant.

Embodiments of the present invention may be used to determine whetherone or more participants have provided incorrect versions of severaltypes of incorrect target shares, i.e. target shares that have not beencalculated correctly and which will therefore result in an incorrectsignature share and an invalid signature.

One type of target share is referred to as a multiplicative share. Themultiplicative share is a product of two secret shares, i.e. a productof a respective share of one shared secret and a respective share ofanother shared secret. For instance, one of the shared secrets may be anephemeral private key and the other may be a blinding key used to blind(obfuscate) the ephemeral private key.

Another type of target share is referred to as an intermediary share.The intermediary share is a sum of a secret share and a product of twosecret shares, i.e. a sum of i) a respective share of one shared secretand ii) a product of respective shares of two different shared secrets.For instance, the three shared secrets may be an ephemeral private key,a private key and a blinding key. Note that the intermediary share maybe calculated based on an inverse ephemeral private key share. Note alsothat the blinding key used to calculate the intermediary share may be adifferent blinding key compared to the one used to calculate themultiplicative share, although that is not essential.

Embodiments will be described from the viewpoint of a first participant102 a, but it will be appreciated that the same methods may be performedby any of the participants 102. The first participant 102 a has a firstshare of a first shared secret and a first share of a second sharedsecret. The first participant 102 a also has a public key correspondingto the first shared secret and a public key corresponding to the secondshared secret. The first participant 102 a may also have a first shareof a third shared secret, and a public key corresponding to the thirdshared secret. Note that “first” is used merely as a distinguishinglabel and does not necessarily mean first in a sequence.

Each other participant also has respective shares of the first andsecond shared secrets, and optionally the third shared secret. Eachother participant also has public keys corresponding to the sharedsecrets.

In some examples, some or all of the shared secrets may be calculatedusing JVRSS as described above. Other secret sharing schemes may be usedinstead. The public keys corresponding to the shared secrets may becalculated using the obfuscated coefficients shared during JVRSS, i.e.using the obfuscated coefficients shared during step 4 of the JVRSSmethod described in the preliminaries. Normally, the obfuscatedcoefficients a_(jk)·G are communicated during JVRSS to verify one's ownshare. Now, for the purposes of the present invention, each participantverifies the respective share of each other participant. Note that thesteps of JVRSS are not modified. Rather, the verification of the otherparticipants shares is in addition to JVRSS.

The first participant 102 a generates a first target share. The firsttarget share may be generated based on (i.e. is a function of) the firstshare of the first shared secret and the first share of the secondshared secret. The target share may also be a function of the firstshare of the third shared secret. Each other participant generates arespective target share in the same way using their respective shares.

The first participant 102 a generates a first target value. Note thatthe first target value is merely an integer value. The first targetvalue is generated based on (i.e. is a function of) the first targetshare and a set of target shares generated by the other participants.The set of target shares is made up of a predetermined number of targetshares. The predetermined number is based on the degree of the sharedsecrets, i.e. the degree of the shared secret polynomials. In otherwords, the first target value requires a predetermined minimum ofrespective target shares in order to be generated correctly. The firsttarget value may be generated by interpolating over the first targetshare and the set of target shares.

Each participant 102 may have a respective index, e.g. 1, 2, 3, etc. Thefirst participant 102 a may generate the first target value using thefirst target share and respective target shares from participants withindices following the index of the first participant 102 a. That is, ifthe first participant 102 a has index 1, the first participant 102 a mayuse target shares from participants with indices 2, 3, and so on, untilthe required number of target shares is reached.

Each other participant generates a respective target value based ontheir respective target share and the predetermined number of targetshares. Depending on the size of the group, one or more participants maygenerate their respective target value based on a different set oftarget shares.

The first participant 102 a may obtain the other target shares directlyfrom the respective participants. Or, the other participants maybroadcast their shares. Or, one or more participants may collect thetarget shares and forward them to the first participant 102 a.Similarly, the first participant 102 a may broadcast the first targetshare to the other participants, or transmit the first target sharedirectly to individual ones of the participants. In general, anycommunication between the participants may be via a secure communicationchannel.

The first participant 102 a generates a target public key. The targetpublic key is generated based on (i.e. is a function of) the firsttarget value and a generator point. Each other participant alsogenerates a target public key based on their respective target value andthe generator point.

The first participant 102 a generates a first verification share. Thefirst verification share may be generated based on (i.e. a function of)the first share of the first shared secret and the public keycorresponding to the second shared secret. Each other participantgenerates a respective verification share in the same way using theirrespective share.

The first participant 102 a generates a verification public key. Theverification public key is generated based on (i.e. is a function of)the first verification share and a set of verification shares generatedby respective participants. The set of verification shares is made up ofa predetermined number of verification shares. The predetermined numberis based on the degree of the shared secrets, i.e. the degree of theshared secret polynomials. In other words, the verification key requiresa predetermined minimum of respective verification shares in order to begenerated correctly. The verification key may be generated byinterpolating over the first verification share and the set ofverification shares. In some examples, the interpolation may be ellipticcurve interpolation, i.e. the sum is elliptic curve point addition.

The first participant 102 a may generate the verification public keyusing the first verification share and respective verification sharesfrom participants with indices following the index of the firstparticipant 102 a, similar to how the target value may be generated.

Each other participant generates a respective verification key based ontheir respective verification share and the predetermined number ofverification shares. Depending on the size of the group, one or moreparticipants may generate their respective verification key based on adifferent set of verification shares.

The first participant 102 a may obtain the other verification sharesdirectly from the respective participants. Or, the other participantsmay broadcast their shares. Or, one or more participants may collect theverification shares and forward them to the first participant 102 a.Similarly, the first participant 102 a may broadcast the firstverification share to the other participants, or transmit the firstverification share directly to individual ones of the participants.

The first participant 102 a then compares the target public key and theverification public key. If the two public keys are not the same, thenthe first participant 102 a can be sure that at least one of the targetshares has been calculated incorrectly. In some instances, the firstparticipant 102 a obtains confirmation from all other participants thatthe target public key and verification public key that thoseparticipants have calculated are the same. In that case the firstparticipant 102 a can be confident that the target shares have beencalculated correctly.

Therefore the target value can be used to calculate a first signature,which is then sent to a coordinator 101. If, on the other hand, thetarget public key is not the same as the verification public key, thefirst participant 102 a knows that at least one of the target shares hasbeen incorrectly calculated. The first participant 102 a will then notuse the target value in further calculations and thus prevent an invalidsignature from being calculated.

Similarly, the other participants also perform the same comparison.

The group may have a size of N≥2t+1. The threshold of the shared secretsand of the threshold signature may be t+1, where t is the degree of theshared secret polynomial. In this example, the first predeterminedamount (i.e. the number of other target shares required to generate thefirst target value) is 2t and the second predetermined amount (i.e. thenumber of other verification shares required to generate theverification public key) is t.

If the group has a size of N>2t+1 the first participant 102 a mayidentity those participants that have provided an incorrect targetshare. To do so, the first participant 102 a generates a plurality ofverification public keys. Each of the plurality of verification publickeys is generated used the first verification share and a different setof verification shares from other participants (still with the requirednumber of verification shares). The first participant 102 a thencompares the plurality of verification public keys. Any verificationpublic key that does not match the majority of the verification publickeys has been calculated using a verification share provided by adishonest (i.e. malicious) participant. Therefore the first participant102 a can deduce which of the participants is dishonest and thereforewill have provided an incorrect target share.

As mentioned above, the first shared secret may be a first blinding keyand the second shared secret may be an ephemeral private key. The targetvalue may be a multiplicative key, e.g. a product of the first blindingkey and the ephemeral private key (or inverse thereof).

In other examples, the first shared secret may be an ephemeral privatekey (or inverse thereof), the second shared secret may be a sharedprivate key and the third shared secret may be a second blinding key.The target value may be an intermediary key.

It is also possible to identify if a participant 102 has provided acorrect signature share, as opposed to a target share or target valuethat is then used to calculate a signature share. In other words, aparticipant 102 can calculate a signature share and provide data thatcan be used by a coordinator to verify whether the signature share hasbeen calculated correctly. Similar to the examples given above, thismethod will be described from the perspective of the first participant102 a, but it will be appreciated that any participant may perform thesame method.

The first participant 102 a has a respective share of each of a sharedprivate key, a shared ephemeral key, a first shared blinding key and asecond shared blinding key. The shares of the shared keys may becalculated using JVRSS, as described elsewhere herein. Alternativesecret sharing schemes may be used instead.

The signature share may be based on a respective share of the sharedephemeral key (or an inverse thereof), a message, a respective share ofthe shared blinding key, the shared private key and a public keycorresponding to the shared ephemeral private key. Note that althoughthe signature share may be based on a whole key (as opposed to a shareof the key), that does not necessarily mean that a participant hasaccess to the whole key, e.g. the shared private key.

In general, the signature share may be calculated as sum of at least twoterms. Each term is calculated based on data that may be publicly known(or at least known to the other participants and/or coordinator), e.g.the message. Each term is also calculated based on data that shouldremain private to a given participant, e.g. a respective share of ashared key.

The first participant 102 a provides, to the coordinator 101, a publickey for each term of the signature share. The public key corresponds tothe data of each term that is not publicly known. Note that theinformation that is shared to calculate these public keys may be sharedduring JVRSS. That is, the information need not be shared againseparately by each participant, although that is not excluded.

The first participant 102 a calculates a first public key correspondingto a first inverse ephemeral private key share. I.e. a public keycorresponding to the inverse of a first share of the ephemeral privatekey. The first public key is calculated based on (i.e. is a function of)the inverse of the ephemeral private key obfuscated with the firstblinding key, or in other words, the inverse of the ephemeral privatekey multiplied by the first blinding key. The first public key is alsobased on a public key corresponding to a first share of the firstblinding key. The first participant 102 a sends the first public key tothe coordinator 101.

The inverse of the ephemeral private key multiplied by the firstblinding key may be calculated based on a respective multiplicativeshare provided by each participant. Multiplicative shares have beendiscussed above. In summary, each participant may calculate amultiplicative share based on a first ephemeral private key share and afirst blinding key share, e.g. the first participant 102 a calculate afirst multiplicative share. The first participant 102 a may thencalculate a multiplicative key based on the first multiplicative shareand a respective multiplicative share from the other participants. Thefirst participant 102 a may then calculate the inverse of themultiplicative key. The first public key is then based on a public keycorresponding to the inverse of the multiplicative key.

The first participant 102 a also calculates a second public key. Thesecond public key corresponds to a pre-signature share. The secondpublic key is based on (i.e. is a function of) a third public key and afourth public key. The third public key is a public key corresponding toan intermediary value. The intermediary value is calculated based on aninverse of the ephemeral private key, the shared private key and thesecond blinding key. The fourth public key is a public key correspondingto a first share of the second blinding key. The first participant 102 asends the second public key to the coordinator 101.

One way of calculating the intermediary value has been discussed above.In summary, the intermediary value may be calculated based on a firstintermediary share calculated by the first participant 102 a andrespective intermediary shares calculated by the other participants. Thefirst participant 102 a may calculate a first intermediary share may becalculated based on an inverse of a first ephemeral private key share, afirst private key share and a first share of the second blinding key.

The coordinator may already have access to the signature sharecalculated by the first participant 102 a. Alternatively, the firstparticipant 102 a may provide the first and second public keys to thecoordinator at the same time as, or before, providing the firstsignature share.

The first signature share is calculated based on a first share of theephemeral private key, a message, a public key corresponding to theshared ephemeral private key, and a first share of the second blindingkey. The coordinator 101 has access to the message and the public keycorresponding to the shared ephemeral private key. The coordinator 101may then use the first public key and the second public key obtainedfrom the participant, along with the message and the public keycorresponding to the shared ephemeral private key to calculate a publickey corresponding to a candidate first signature share. I.e. anobfuscated candidate first signature share (candidate in the sense thatat this point the coordinator 101 does not know if the public keycorresponds to the same first signature share). The coordinator 101 alsocalculates a public key corresponding to the first signature share, i.e.the signature share provided by the first participant 102 a. If thepublic key corresponding to the candidate first signature share matchesthe public key corresponding to the first signature share, thecoordinator can be sure that the first participant 102 a has calculateda correct signature share. The coordinator 101 may then use the firstsignature share to calculate a signature based on the first signatureand one or more additional signature shares from respectiveparticipants. If the public key corresponding to the candidate firstsignature share does not match the public key corresponding to the firstsignature share, the coordinator 101 knows that the first participant102 a has not calculated a correct signature share and therefore may beattempting a denial-of-service attack.

In some examples, the coordinator may perform this verification checkbefore generating the signature. That is, before the coordinatorgenerates a complete signature based on the participants' signatureshares, the coordinator may verify that each participant has correctlycalculated their respective signature shares. In other examples, thecoordinator may perform this verification check after generating thesignature. That is, after the coordinator has generated a completesignature, the coordinator may verify that the signature is a validsignature. If the signature is invalid, the coordinator can use theverification check to identify which participant(s) has/have provided anincorrect signature share.

Note that in some examples, rather than the first participant 102 acalculating the first and second public keys and sending them to thecoordinator, the coordinator can instead calculate the first and secondpublic keys. This prevents the first participant 102 a from sendingincorrect values of the first and second public keys. The coordinator101 may then calculate the public key corresponding to the candidatesignature share using the calculated first and second public keys. Inthis example the coordinator 101 is one of the participants and uses theinformation shared during the generation of respective signature sharesby the respective participants to calculate the first and second publickeys. For instance, the coordinator may use the obfuscated coefficientsshared during step 4 of JVRSS to calculate:

${\left( {\alpha_{i} \cdot G} \right) = {\sum\limits_{j = 1}^{N}{\sum\limits_{k = 0}^{t}{i^{k}\left( {\alpha_{jk} \cdot G} \right)}}}},$${\left( {\beta_{i} \cdot G} \right) = {\sum\limits_{j = 1}^{N}{\sum\limits_{k = 0}^{t}{i^{k}\left( {\beta_{jk} \cdot G} \right)}}}},$

(α_(i)·G) and (β_(i)·G) may then be used to calculate the first andsecond public keys respectively. See section “catching incorrectsignature shares” for further details.

Further illustrative examples of some embodiments of the invention arenow provided.

In both the optimal and non-optimal threshold signature schemesmentioned above (and described in more detail below) there are twointermediary calculations before the calculation of the signatureshares. Currently there are no steps taken to ensure the participantsare sharing the correct values, and therefore an adversary maycontribute incorrect values that may prevent a correct signature beingcalculated. The following describes methods to prove that thecalculations with shares are done correctly.

Each participant who will verify the calculations needs to calculate theobfuscated shares corresponding to other participants secret shares foreach shared secret. That is, all participants calculate some or all of:

${\left( {a_{i} \cdot G} \right) = {\sum\limits_{j = 1}^{N}{\sum\limits_{k = 0}^{t}{i^{k}\left( {a_{jk} \cdot G} \right)}}}},$${\left( {k_{i} \cdot G} \right) = {\sum\limits_{j = 1}^{N}{\sum\limits_{k = 0}^{t}{i^{k}\left( {k_{jk} \cdot G} \right)}}}},$${\left( {\alpha_{i} \cdot G} \right) = {\sum\limits_{j = 1}^{N}{\sum\limits_{k = 0}^{t}{i^{k}\left( {\alpha_{jk} \cdot G} \right)}}}},$${\left( {\beta_{i} \cdot G} \right) = {\sum\limits_{j = 1}^{N}{\sum\limits_{k = 0}^{t}{i^{k}\left( {\beta_{jk} \cdot G} \right)}}}},$

for each participant i, using the obfuscated coefficients shared inJVRSS. These will be used in some of the verification steps ofcalculations with shares.

Catching Incorrect Multiplicative Shares

It is possible to verify the multiplication of shared secrets iscorrect. If this is not verified, then the calculation of the inverseephemeral key may turn out to be incorrect. First note that at thispoint, each participant i has two shares a_(i) and b_(i) and knowledgeof the corresponding public keys aG, bG. In order to verify that themultiplication of two shared secrets is correct, the participants takethe following steps:

-   -   1. Each participant calculates their multiplicative share        μ_(i)=a_(i)b_(i) and a verification share a_(i)bG. The second is        the multiplication of a_(i) with the public key bG corresponding        to the shared secret b.    -   2. Each participant i broadcasts these values.    -   3. Participant i calculates μ=interpolate(μ_(i), . . . , μ_(i′))        where i′ is i+2t. That is, each participant calculates the        result μ with their own and the next 2t shares only. If they        reach the end of the list of participants in the group and do        not have 2t+1 shares yet, they return to the first share in the        list and continue from there.    -   4. Each participant uses this result μ to calculate μG.    -   5. Each participant also calculates abG=ECinterpolate(a_(i)bG, .        . . , a_(i′)bG) where in this case i′ is i+t. That is, each        participant uses their own and the next t shares to calculate        the result. Note that ECinterpolate is the same as interpolate        except the sum is elliptic curve point addition instead of usual        arithmetic addition.    -   6. Finally, each participant compares abG and μG. If they are        the same, they know that μ is equivalent to ab and this can be        used in calculations.

We now show why it is impossible to successfully cheat if the schemeuses this verification method.

If participant k wants to cheat, they will send a share that is not themultiplication of their shares a_(k)b_(k). If they send an incorrectshare, participant k would send a share that we write asa_(k)b_(k)+δ_(k) without loss of generality. If one were to interpolateover the shares a_(i)b_(i) including this incorrect share, the followingwould be calculated

${{ab} + \delta_{1}} = {{{interpolate}\left( {{a_{i}b_{i}},\ldots} \right)} = {\left( {\sum\limits_{i = 1}^{{2t} + 1}{a_{i}b_{i}{\prod\limits_{\underset{j \neq i}{1 \leq j \leq {{2t} + 1}}}\frac{- j}{i - j}}}} \right) + {\delta_{k}{\prod\limits_{\underset{j \neq k}{1 \leq j \leq {{2t} + 1}}}\frac{- j}{i - j}}}}}$

As above, we can write the incorrect result as (ab+δ₁)G without loss ofgenerality. We see from the equation above that

$\delta_{1} = {\delta_{k}{\prod\limits_{\underset{j \neq k}{1 \leq j \leq {{2t} + 1}}}\frac{- j}{k - j}}}$

On the other hand, an adversary may send a_(k)bG+δ_(k)′G in place of thecorrect value a_(k)bG. Similarly, we find that after EC interpolationover the a_(i)bG values, we find the result

$\delta_{2} = {\delta_{k}^{\prime}{\prod\limits_{\underset{j \neq k}{1 \leq j \leq {t + 1}}}{\frac{- j}{k - j}.}}}$

Now an adversary may be able to find values for δ_(k) and δ_(k)′ thatsatisfy these equations and δ₁=δ₂. However, consider the nextparticipant i=2. In their calculation, the adversary would need to addvalues δ_(k) and δ_(k)′ that result in

$\delta_{1} = {\delta_{k}{\prod\limits_{\underset{j \neq k}{2 \leq j \leq {{2t} + 2}}}\frac{- j}{k - j}}}$and$\delta_{2} = {\delta_{k}^{\prime}{\prod\limits_{\underset{j \neq k}{2 \leq j \leq {{2t} + 2}}}{\frac{- j}{k - j}.}}}$

There is no longer a single solution for either δ₁ or δ₂. Since allparticipants broadcast their shares, an adversary cannot send twodifferent incorrect shares. They will be caught. It may be possible toidentify who the adversaries are when the group size is larger than2t+1. If we assume the worst-case scenario with the number ofadversaries being t, there will be at least two subsets a_(i)bG thatgenerate the correct value of abG. By finding the two sets that generatethe same value, this identifies a set of honest participants. Any othersubsets of a_(i)bG that generate that same value are sets of honestparticipants. The adversaries are the remaining parties that do not formpart of a set that results in the correct value of abG.

In other words, step 3 of the above method is performed using 2t+1shares. If the group size is 2t+1 then there is only one value tocalculate abG. But if the group size is greater than 2t+1, eachparticipant will have more than one value to calculate abG. Thereforethe participants can compare the values and see which are the same. Thesubtlety that reveals any incorrect shares is due to the interpolationin step 5. This step is only over t+1 shares, so this will reveal if anyincorrect shares are present—there will be 2t+1 different sets that arebeing interpolated over. And as motivated above, one only needs tointerpolate two different sets to show if an incorrect share is present.

Note that if the group size is 2t+1 and the number of adversaries is t,it is not possible to definitively determine the adversaries. This isbecause the correct value will only appear out of one subset of values,but this subset cannot be determined.

In the threshold signature schemes, this verification may be used forthe multiplication of the blinding key share and ephemeral key sharewith a_(i)=α_(i) and b_(i)=k_(i).

Catching Incorrect Intermediary Shares

In the case of the threshold-optimal scheme, there is another value thatis calculated with shares before the signature. This is called theintermediary share λ_(i)=k_(i) ⁻¹a_(i)+β_(i). At this point, eachparticipant i has three shares a_(i), b_(i), and c_(i) and knowledge ofthe corresponding public keys aG, bG, cG. The following steps are taken:

-   -   1. Each participant calculates their intermediary share        λ_(i)=a_(i)b_(i)+c_(i) and a verification share a_(i)bG. The        second is the multiplication of a_(i) with the public key bG        corresponding to the shared secret b.    -   2. Each participant i broadcasts these values.    -   3. Participant i calculates λ=interpolate (λ_(i), . . . ,        λ_(i′)) where i′ is i+2t. That is, each participant calculates        the result λ with their own and the next 2t shares only. If they        reach the end of the list of participants in the group and do        not have 2t+1 shares yet, they return to the first share in the        list and continue from there.    -   4. Each participant uses this result λ to calculate λG.    -   5. Each participant also calculates        (ab+c)G=ECinterpolate(a_(i)bG, . . . , a_(i′)bG)+cG where is i+t        where in this case i′ is i+t. That is, each participant uses        their own and the next t shares to calculate the result. Note        that ECinterpolate is the same as interpolate except the sum is        elliptic curve point addition instead of usual arithmetic        addition.    -   6. Finally, each participant compares (ab+c)G and λG. If they        are the same, they know that λ is equivalent to ab+c and this        can be used in calculations.

The argument for why adversaries will not succeed is the same as theprevious section.

Catching Incorrect Signature Shares

It is possible to find an incorrect signature share if the signaturefails the verification, with the information obtained in JVRSS. This canbe done for both the non-optimal scheme and for the optimal scheme.

For the non-optimal threshold signature scheme, the following is done.Given participant i's non-optimal signature share (r, s_(i)) wheres_(i)=k_(i) ⁻¹(e+a_(i)r), one can verify is this is the correctsignature using normal ECDSA signature verification, using theobfuscated value a_(i)·G as the public key, and the hash of the messagee. If the verification does not hold, the coordinator knows that this isan incorrect share from participant i.

In the optimal threshold scheme as described below, the standard ECDSAverification cannot be done as the signature has the form (r, s_(i))with

s _(i) =k _(i) ⁻¹ e+r(k ⁻¹ a+β−β _(i)).

Standard signature verification verifies the ephemeral key that iscommon across the whole expression, but this cannot be done in thiscase. Instead, verifying participants must first calculate:

k _(i) ⁻¹ ·G=(kα)⁻¹(α_(i) ·G),

σ_(i) ·G=(k ⁻¹ a+β)·G−(β_(i) ·G).

The coordinator 101 then stores (k_(i) ⁻¹·G, σ_(i)·G) for participant i.When they receive participant i's threshold optimal share (r,s_(i)=k_(i) ⁻¹e+r(k⁻¹a+β−β_(i))), they verify it by checking if

s _(i) ·G

e(k _(i) ⁻¹ ·G)+r(σ_(i) ·G).

If this check holds, then the coordinator 101 can be sure thatparticipant i sent the correct share. With these additionalverifications above, any adversaries that attempt a denial-of-serviceattack by sending incorrect shares will be caught

Threshold Optimal Signatures

The following provides a description of a threshold optimal ECDSA schemefirst detailed in GB2005953.1. Embodiments of the present invention maybe used to identity denial-of-service attacks when calculating asignature share according to this scheme.

FIG. 1 illustrates an example system 100 for implementing a thresholdoptimal signature scheme, e.g. a threshold optimal ECDSA scheme. Asshown, the system 100 comprises a plurality of parties, including acoordinator 101 and a group of participants 102. Only three participants102 are shown in FIG. 3 , but it will be appreciated that in general thesystem may comprise any number of participants. Furthermore, in FIG. 1the coordinator 101 is shown as being distinct from the participants102, but in some embodiments the coordinator 101 may also be one of theparticipants 102, e.g. the first participant 102 a. Each of thecoordinator 101 and participants 102 operates respective computingequipment.

Each of the respective computing equipment of the respective parties(i.e. coordinator 101 and participants 102) of the system 100 comprisesrespective processing apparatus comprising one or more processors, e.g.one or more central processing units (CPUs), accelerator processors(GPUs), application specific processors and/or field programmable gatearrays (FPGAs). The respective computing equipment may also comprisememory, i.e. computer-readable storage in the form of a non-transitorycomputer-readable medium or media. The memory may comprise one or morememory units employing one or more memory media, e.g. a magnetic mediumsuch as a hard disk; an electronic medium such as a solid-state drive(SSD), flash memory or EEPROM; and/or an optical medium such as anoptical disk drive. The respective computing equipment may comprise atleast one user terminal, e.g. a desktop or laptop computer, a tablet, asmartphone, or a wearable device such as a smartwatch. Alternatively oradditionally, the respective computing equipment may comprise one ormore other networked resources, such as cloud computing resourcesaccessed via the user terminal (the cloud computing resources comprisingresources of one or more physical server devices implemented at one ormore sites). It will be appreciated that any act described as beingperformed by a party of the system 100 may be performed by therespective computing apparatus operated by that party.

The coordinator 101 is the party that initiates the signature using athreshold number of signature shares generated by respectiveparticipants of a group of participants 102. That is, the coordinator101 generates the signature on a message to be signed. Again, note thatgenerating a signature on a message is taken to mean that a signature isdependent on the message to be signed, or put another way, the signatureis a function of the message to be signed. The coordinator 101 may alsobe the party that sends the signature, and optionally the message, to athird party 103 or otherwise outputs the signature. For instance, thethird party 103 may be a certificate authority or other form ofauthority, or another user. In other examples, the signature may berecorded, e.g. in a database or other document. In some examples, thesignature may be made available to the public, e.g. recorded on awebsite or other publicly accessible medium.

The coordinator 101 may transmit a message to be signed to theparticipants 102. The message may be transmitted to all of theparticipants 102, or to a subset of the participants, e.g. the thresholdnumber of participants. In the example of FIG. 1 , the group ofparticipants comprises three participants 102 a, 102 b, 102 c. Thecoordinator 101 may transmit the message to one participant who thenforwards the message to one, some or all of the other participants.

The message may be transmitted over the internet using a LAN or WANconnection, or via alternative wired or wireless communication means.The message may be transmitted to each participant 102 individually,e.g. via a secure communication channel between the coordinator 101 andeach participant 102, or broadcast to the group as a whole, e.g. viaemail or other means. The message may be transmitted in raw form, or inencrypted form. For instance, the message may be hashed one or moretimes.

One or more of the participants 102 may obtain the message viaalternative means, i.e. not from the coordinator 101. For example, themessage may be generated by one of the participants 102, or otherwiseavailable, e.g. publicly. One or more participants 102 may receive themessage from a third party 103. A participant 102 that obtains themessage may transmit the message (in raw or encrypted form) to one ormore other participants 102. For instance, the first participant 102 maytransmit the message to the second participant 102 b and/or the thirdparticipant 102 c.

The coordinator 101 obtains (e.g. receives) a threshold number ofsignature shares. In the example of FIG. 1 , the threshold is two andonly the first participant 102 a and the second participant 102 b decideto generate a respective signature share. For instance, one or more ofthe participants 102 that generate a signature share may transmit theirrespective share directly to the coordinator 101, e.g. via a securecommunication channel. Alternatively, one or more of the participants102 may broadcast their respective shares, and/or make their sharepublicly available. As set out above, the coordinator 101 may also be aparticipant. In those embodiments, the coordinator 101 may also generatea respective signature share. In that sense, obtaining at least one ofthe threshold number of signature shares means generating at least onesignature share, and therefore the coordinator 101 only need receive oneless than the threshold number of signature shares.

In order to obtain the signature shares, the coordinator 101 maytransmit a request for signature shares on a message. For instance, thecoordinator 101 may transmit a request for signature shares to one, someor all of the group of participants 102.

Having obtained at least the threshold number of signature shares, thecoordinator 101 generates the signature using the obtained shares. Thecoordinator 101 may then broadcast or transmit the signature to one ormore other entities. Additionally or alternatively, the coordinator maystore the signature, and/or record the signature as part of a digitalrecord, e.g. in an email or other document.

The method for generating a signature share s_(i) will now be described.The method is described from the perspective of the first participant102 a, but it will be appreciated that each other participant 102 thatgenerates a signature share does so using an equivalent method, albeitusing certain data specific to that other participant 102.

Each participant 102 has access to the following data items: arespective private key share a_(i) (i.e. a share of the same privatekey), a respective ephemeral private key share k_(i), and a commonshared value r that is generated based on a common ephemeral public keyk·G. The common ephemeral public key corresponds to, i.e. is generatedbased on, the ephemeral private key. Here, a value or key may be commonin the sense that each participant has access to that same value or key.Note that unless specified, generating a second key based on a first keydoes not necessarily imply that the first key itself is known. Examplesof how these data items may be generated are provided below.

The first participant 102 a obtains, or already has access to, a messageto be signed. The message may be in its raw form (e.g. plaintext), or inan encrypted or otherwise encoded for (e.g. ciphertext). The firstparticipant 102 a may obtain the message (in either form) from thecoordinator and/or from another participant 102. Alternatively, thefirst participant 102 a may generate the message to be signed.

The first participant 102 a generates a first signature share s₁. Notethat “first” in this context is just used as an arbitrary label todistinguish the particular participant and the particular signatureshare from other participants and signature shares respectively, anddoes not necessarily imply that the first participant 102 a is the firstparticipant to generate a signature share s_(i), or that the firstsignature share s₁ is the first in an ordered list of signature sharess_(i).

In some embodiments, the first signature share s₁ may be generated basedon, i.e. is a function of, a first message-independent component (MIC)and a first message-dependent component (MDC), where again “first” isjust used as a label. The MIC is generated independently of the message.That is to say, the MIC is not a function of the message to be signed(i.e. the MIC is not generated based on the message), and knowledge ofthe message is not required to generate the MIC. In contrast, the MDC isa function of the message to be signed and knowledge of the message isrequired to generate the MDC.

In other embodiments, the first signature may not be a function of thefirst message-independent components (MIC). In these embodiments, thefirst message-independent component is generated and made available tothe coordinator 101, e.g. transmitted to the coordinator 101 orbroadcast to one or more participants 102. The first message independentcomponent (MIC) may be shared with the coordinator in advance of, andseparately from the first signature share.

The coordinator 101 may obtain a respective message-independentcomponent (MIC) from at least the threshold number of participants, andgenerate the signature based on the respective signature shares (whichare a function of the respective message-dependent components (MDC)) andthe respective message-independent components (MIC). More details areprovided below.

Since the MIC does not require knowledge of the message, the MIC can bepre-calculated. In other words, the MIC can be generated beforeobtaining the message. Therefore a plurality of different MICs can bepre-calculated, each for use in generating a different respectivesignature shares s₁′ for signing different messages, where the prime (′)indicates that it is a different instance of the first signature share.

Having generated the first signature share s₁, the first participant 102a makes the first signature share s₁ available to the coordinator 101for generating the signature s on the message. If the first participant102 a is the coordinator 101, making the first signature share s₁available to the coordinator 101 may merely mean outputting the firstsignature share s₁ to a function for generating the signature s.Otherwise, the first participant 102 a may transmit the first signatureshare s₁ to the coordinator 101, or to one or more other participants102 for forwarding to the coordinator 101, or broadcast the firstsignature share s₁, or use a combination of these options.

As stated above, the first signature share s₁ may be generated based ona first MIC and a first MDC. Regardless of whether the first signatureshare is a function of the first MIC, the first MIC is generated basedon (i.e. is a function of) the first private key share a₁ (i.e. theshare of the private key a known to the first participant 102 a). Thefirst MIC may also be based on the first ephemeral private key share k₁(i.e. the share of the ephemeral private key k known to the firstparticipant 102 a) and the shared value r generated based on theephemeral public key k·G corresponding to the ephemeral private key k.The first MDC is generated based on (i.e. is a function of) the message(in raw or encrypted form) and may also be generated based on the firstephemeral private key share k₁. Variations of the MIC and MDC areprovided below.

Preferably, the first private key share a₁ may be calculated using ajoint secret sharing scheme, e.g. using the JVRSS technique describedabove. For instance, the first participant 102 a may have an index of 1,and generate the first private key share using a₁=JVRSS(1) forparticipant 1, where the private key is denoted by a. Each participantmay generate a respective private key share a_(i). For instance, thesecond participant 102 b may generate a second private key share usinga₂=JVRSS(2) for participant 2, and so on.

Generating a first private key share a₁ using a joint secret sharescheme may comprise generating a set of numbers a_(ij)∈_(R)

_(n)\{0}, ∀j=0, . . . , t, and then generating a first polynomialf₁(x)=a₁₀+a₁₁x+ . . . +a_(1t)x^(t) mod n, where the set of numbers arethe coefficients of the polynomial. Each of the other participants 102generates a respective polynomial using a respective set of numbers. Forinstance, the second participant 102 b generates a second polynomialf₂(x)=a₂₀+a₂₁x+ . . . +a_(2t)x^(t) mod n. The participants 102 thentransmit, to each other participant, a value of their respectivefunction evaluated at the index of that other participant. For instance,the first participant 102 a evaluates f₁(2) for the second participant102 b and then transmits that value to the second participant 102 b,evaluates f₁(3) for the third participant 102 c and then transmits thatvalue to the third participant 102 c, and so on. The first participant102 a obtains the respective values generated, as a function of thefirst participant's index, by the other participants 102. The values maybe transmitted over the internet, or via other means. The values may betransmitted via respective secure communication channels betweenrespective pairs of the participants. Instead of transmitting directly,one or more participants 102 (e.g. the first participant 102 a) maybroadcast their respective values. Having obtained at least thethreshold number of values from at least the threshold number ofparticipants, the first participant 102 a generates the first privatekey share based on the first value and each other obtained data value,e.g. f₂(1), f₃(1), etc.

The first participant may calculate the corresponding public key a·Gbased on a set of obfuscated coefficients, where the coefficients areused to generate the respective private key shares a_(i) of eachparticipant 102. That is, when generating the ephemeral private keyshare k_(i), each participant 102 may share the obfuscated coefficientsa_(ij)·G with each other participant 102. The coefficients areobfuscated by a common generator point G on the chosen elliptic curve.These obfuscated coefficients may be transmitted between participants102 directly, or broadcast to the group. For instance, the firstparticipant 102 a may broadcast the obfuscated coefficients a₁₀·G,a₁₁·G, a₁₂·G, and so on. The public key corresponding to the private keymay then be calculated as

$P = {{a \cdot G} = {\sum\limits_{j = 1}^{N}{\left( {a_{j0} \cdot G} \right).}}}$

Note that the private key shares a_(i) may be generated using analternative method, i.e. not using the JVRSS method described above.Whilst each participant requires a share of a private key a in order togenerate a respective signature share s_(i), the particular method forgenerating the private key share may be chosen to suit the particularscenario, e.g. whether some, all or none of the participants can betrusted, or whether a trusted dearer is available to distribute keyshares, etc. Methods for generating shares of a private key are, inthemselves, known in the art. Similarly, method for distributing sharesof a private key (or other such data) are, in themselves, known in theart. That being said, the private key share a_(i) may be generated in anumber of ways. For instance, a dealer (e.g. the coordinator) may beused to generate and distribute one, some or all of the private keyshares a_(i), e.g. using a Shamir's secret sharing scheme. One suchscheme that may be used for generating and distributing private keyshares a_(i) is described in WO2017145010A1.

Similarly, an alternative to JVRSS may be used when generating some orall of the private key shares described below, e.g. the ephemeralprivate key share k_(i), the first blinding value key share a_(i) and/orthe second blinding value key share β_(i).

The first ephemeral private key share k₁ may be calculated using a jointsecret sharing scheme, e.g. using the JVRSS technique described above.For instance, the first participant 102 a may have an index of 1, andgenerate the first ephemeral private key share using k₁=JVRSS(1) forparticipant 1, where the ephemeral private key is denoted by k. Eachparticipant 102 may generate a respective ephemeral private key sharek_(i). For instance, the second participant 102 b may generate a secondephemeral private key share using k₂ 32 JVRSS(2) for participant 2, andso on.

Generating the first ephemeral private key k₁ share using the jointsecret sharing scheme comprises the same steps described above forgenerating the first private key share a₁, except that the randomnumbers used for generating the ephemeral private key share k₁ aredifferent numbers comparted to those used for generating the private keyshare a₁.

Note that the same private key a, and private key shares a_(i) are usedfor each signature, whereas the ephemeral private key k and ephemeralprivate key shares k_(i) are changed for each signature.

The shared value r is generated based on the ephemeral public key k·Gcorresponding to the ephemeral private key k. The ephemeral public key(x, y) comprises two components, usually referred to as the x and ycomponents. The shared value r may be a function of the x component ofthe ephemeral public key, e.g. r=x mod n.

The ephemeral public key k·G may be generated based a set of obfuscatedcoefficients, wherein the coefficients were used to generate therespective ephemeral private key shares k_(i) of each participant 102.That is, when generating the ephemeral private key share k_(i), eachparticipant 102 shares the obfuscated coefficients k_(ij)·G with eachother participant 102. The coefficients are obfuscated by a commongenerator point G on the chosen elliptic curve. These obfuscatedcoefficients may be transmitted between participants 102 directly, orbroadcast to the group. For instance, the first participant 102 a maybroadcast the obfuscated coefficients k₁₀·G, k₁₁·G, k₁₂·G, and so on.The ephemeral public key may then be calculated as

$\left( {x,y} \right) = {\sum\limits_{i = 1}^{N}{\left( {k_{i0} \cdot G} \right).}}$

In some embodiments, the first MIC is generated based on a first inverseshare k₁ ⁻¹ corresponding to the first ephemeral private key share k1.That is, the first inverse share k₁ ⁻¹ is a function of the firstephemeral private key share k₁.

The first inverse share k₁ ⁻¹ may be an inverse of shared secrets, forexample, generated by calculating k₁ ⁻¹=INVSS(1) for participant 1. Asset out above, calculating the inverse of shared secrets comprisescalculating the product of shared secrets. The first participant 102 agenerates an intermediate value μ as the product of the first ephemeralprivate key k and a first blinding key α. For instance, the intermediatevalue may be calculated as by μ=kα=PROSS(1) for participant 1, theresult of which is μ=kα mod n.

This may involve each participant 102 generating a multiplicative shareμ_(i)=k_(i)α_(i), where α_(i) is a share of the first blinding key α.Each participant 102 may calculate their respective share α_(i) of thefirst blinding key α using a joint secret sharing scheme, e.g. using theJVRSS technique described above. For instance, the first participant 102a may have an index of 1, and generate a share of the first blinding keyusing α₁=JVRSS(1) for participant 1. Each participant shares (e.g. viadirect transmission or broadcasting) their respective multiplicativeshare μ_(i), and then generate the intermediate value μ based on each ofthe multiplicative shares μ_(i), e.g. by interpolation. The firstinverse share k₁ ⁻¹ may be generated by calculating the inverse of theintermediate value μ. For instance, the first participant 102 a maycalculate the modular inverse of μ which results in

μ⁻¹=(kα)⁻¹ mod n.

The first participant 102 a may then calculate the first inverse sharek₁ ⁻¹ based on the modular inverse μ⁻¹ of the intermediate value andtheir respective first blinding key share α₁, e.g. by calculating

k ₁ ⁻¹=μ⁻¹α₁.

Note that the use of the blinding key share α_(i) is optional and may beomitted from the above steps.

Optionally, the MIC may be generated based on (i.e. a function of) ashare of a second blinding key β. That is to say, the MIC is also basedon the first share β₁ of the second blinding key β, in addition to thepreviously mentioned data items. The first share of the second blindingkey may be calculated using a joint secret sharing scheme, e.g. usingthe JVRSS technique described above. For instance, the first participant102 a may have an index of 1, and generate the first share of the secondblinding key using β₁=JVRSS(1) for participant 1, where the secondblinding key is denoted by β.

The MIC may be generated based on a first pre-signature share σ1 whichis a function of a first intermediary share λ₁ and a respectiveintermediary share λ_(i) obtained from at least the threshold number ofparticipants 102. That is, each of the participants 102 may generate arespective intermediate share λ_(i) and transmit and/or broadcast thoseintermediate shares λ_(i) to the other participants 102. The firstparticipant 102 a may collect the intermediary shares λ_(i) to generatea common intermediary value λ, e.g. by interpolation of the intermediaryshares λ_(i). The first participant 102 a, (and optionally, the otherparticipants 102) may generate a plurality of pre-signature shares σ₁′,each for use in the generation of different signature shares s₁′.

The first intermediary share λ₁ may be a function of the first privatekey share a₁ and the first inverse share k₁ ⁻¹. In that case, each of atleast the threshold number of participants 102 generates and shares arespective intermediary share λ_(i) that is a function of theirrespective private key a_(i) share and their respective inverse sharek_(i) ⁻¹.

Alternatively, the first intermediary share λ₁ may be a function of thefirst private key share a₁ and the first share of the first blinding keyα₁. In that case, each of at least the threshold number of participants102 generates and shares a respective intermediary share λ_(i) that is afunction of their respective private key share a_(i) and theirrespective share of the first blinding key α₁.

In some embodiments, the first pre-signature share σ₁ may also begenerated based on the first share of the second blinding key β₁. Forinstance, the first intermediary share λ₁ may be a function of the firstshare of the second blinding key β₁. In additional or alternativeembodiments, the first intermediary share λ₁ may also be a function ofthe common value r.

FIG. 2 illustrates an example method 200 for generating a signature on amessage according to embodiments of the invention. Steps S201 to S208are performed by each of a threshold number of participants 102 in thisexample (including the first participant 102 a). Step S209 is performedby a coordinator 101, who may also may one of the participantsperforming steps S201 to S208. It will be appreciated that some of thesteps may be omitted or be performed in a different order.

The example method 200 enables the creation of a shared secret ofthreshold (t+1) in a group of N≥2t+1 participants, where the signingthreshold is also (t+1).

Set-up:

In step S201, each participant 102 calculates a shared private key shareand a corresponding public key. For instance, each participant 102 maycalculate the shared private key, and corresponding public key usingJVRSS and the calculation of the public key given in the preliminaries.At this point, each participant i has a secret key share and public key(a_(i), P), where P is notation for the public key corresponding to theshared private key. The shared private key has a threshold of (t+1).

Pre-Calculation:

In step S202, each participant 102 calculates a shared ephemeral keyshare and a corresponding public key. For instance, each participant 102may calculate a shared ephemeral key using JVRSS and the calculation ofthe public key given in the preliminaries. Each participant 102 may thencalculate an inverse share based on the ephemeral private key. Thisresults in each participant having an inverse share (k_(i) ⁻¹, r), witha threshold of (t+1).

In step S203, each participant 102 creates two different shared blindingkey shares. For instance, each participant 102 may create two sharedsecrets so that participant i has shares α_(i)=JVRSS(i) andβ_(i)=JVRSS(i), each shared secret having a threshold (t+1). Note thatin some examples, not all of the shared secrets need to have the samethreshold.

In step S204, each participant 102 calculates an intermediary share andbroadcasts their intermediary share to the other participants. Forinstance, each participant i may calculate the intermediary shareλ_(i)=k_(i) ⁻¹a_(i)+β_(i). This value has a threshold of (2t+1).

In step S205, each participant 102 calculates an intermediary valuebased on at least the intermediary shares. For instance, eachparticipant 102 may calculate the intermediary value using interpolationover (2t+1) shares λ=interpolate(λ₁, . . . , λ_(2t+1))=k⁻¹a+β.

In step S206, each participant 102 calculates a pre-signature share. Forinstance, each participant i may calculate their pre-signature shareσ_(i)=λ−β_(i)=(k⁻¹a+β)−β_(i). Each participant 102 may store (r, k_(i)⁻¹, σ_(i)), and the private key share and corresponding public key(a_(i), P).

Note that since a different ephemeral key is used for each signature,multiple ephemeral keys can be set up at one time, that is, steps S202to S206 can be repeated to create multiple ephemeral keys duringpre-calculation and stored for later use. These can be executed at thesame time so that there are no additional rounds of communication. Notethat preferably, a different value of α and β should be used for eachsignature.

Signature Generation:

In order to sign a message msg, at least (t+1) participants must performsteps S207 and S208.

In step S207, at least the threshold number of participants 102 obtain amessage to be signed and calculate a message digest. For instance, acoordinator 101 may send a request to (t+1) participants to create asignature share on the message msg. Each participant i may calculate themessage digest e=hash(msg). In some examples, this hash function is thedouble SHA-256 hash function. Alternative hash functions may be used.

In step S208, at least the threshold number of participants 102calculate a signature share and send it to the coordinator 101. Forinstance, each participant i may calculate their signature shares_(i)=k_(i) ⁻¹e+rσ_(i), and then send their signature share (r, s_(i))to the coordinator. Note that the value r may not be sent by allparticipants.

In step S209, the coordinator 101 calculates the signature. Forinstance, the coordinator 101 may calculate s=interpolate(s₁, . . . ,s_(t+1))=k⁻¹(e+ar), and finally the signature (r, s).

There are several alternatives for pre-calculating the messageindependent component of the signature share. These can broadly be splitinto two sets of variations: when to include r in the calculation, andwhen to include (kα)^(−1.) These can be selected independent of eachother and so there are eight variations to the above method 200.

One modification is to store (r, k_(i) ⁻¹, rσ_(i)) during step S206,meaning that r is included in the pre-signature share.

Another modification is that the multiplication with r can also comeearlier during the calculation of the intermediary shares. By defininginstead λ_(i)=rk_(i) ⁻¹a_(i)+β_(i) in step S204, then in step S206,σ_(i)=λ−β_(i)=(rk⁻¹a+β)−β_(i) and the calculation of signature shares iss_(i)=k_(i) ⁻¹e+σ_(i).

Another modification is to instead calculate λ_(i)=α_(i)a_(i)+β_(i) suchthat λ=(kα)⁻¹(αa+β), and σ_(i)=λ−(kα)⁻¹β_(i). The two variations ofincluding r at alternative points can be done in combination with this.Each participant has knowledge of kα as it is calculated in step S202 ofthe pre-calculation. Additionally, all participants 102 broadcast theirλ_(i) share. So each participant 102 has knowledge of (at least) 2t+1shares and the value kα. They can then calculate

λ=(kα)⁻¹×interpolate(λ₁, . . . , λ_(2t+1))

Another modification is to instead calculate the intermediary value asλ=(αa+β) and the pre-signature share as σ_(i)=λ−β_(i). Finally, thesignature share would then be s_(i)=k_(i) ⁻¹e+r(kα)⁻¹σ_(i). The twovariations of when to include r in the calculation can also be done incombination with this. Each participant 102 has knowledge of kα from thecalculation of k_(i) ⁻¹. They can then calculate (kα)⁻¹ mod n with this,and then include it in the calculation of s_(i).

In summary, each participant 102 may generate four secret shares: a_(i),k_(i), α_(i), β_(i). Two products need to be calculated in the examplemethod 200: kα which is then used to calculate (kα)⁻¹α_(i)=k_(i) ⁻¹(interpolation over these shares gives k⁻¹ as the α's will cancel, andk⁻¹a for use in the signature, which uses the first product, and so ifthe shares are expanded, the calculated gives k_(i)⁻¹a_(i)=(kα)⁻¹α_(i)a_(i). Any calculations with the k_(i) ⁻¹ share,which is made of kα and α_(i), can be done by doing the calculation justwith α_(i) itself first, and then multiplying by (kα)⁻¹ where necessary.

One version of the above scheme can be summarised by saying that asignature is calculated using shares that are composed of a messageindependent component (MIC) and a message dependent component (MDC),where the MIC may be based on the pre-signature share σ_(i) and the MDCis based on the message e.

An equivalent scheme comprises calculating the MIC as above, and thenincorporating this in the signature along with the signature shares,e.g. after interpolation of the signature shares which are made of justan MDC. Explicitly, the scheme may be same up to step S206 of thepre-calculation, where the intermediary shares include the r value,λ_(i)=k_(i) ⁻¹a_(i)r+β_(i) such that after interpolation this isλ=k⁻¹ar+β.

At this stage, the participants have knowledge of (r, k_(i) ⁻¹, λ,β_(i)) and store this along with the private key share and correspondingpublic key (a_(i), P),

Then in order to generate their signature share on a given message mwhich is hashed to create the message digest e=hash(m), the participantscalculate

s _(i) =k _(i) ⁻¹ e−β _(i),

and send this to a coordinator. The coordinator then calculates

s = interpolate(s₁, …, s_(t + 1)) + λ,  = k⁻¹e + k⁻¹ar,

resulting in the expected signature share since the β terms cancel.Similar variations of this protocol can be made as above describing whenthe (kα)⁻¹ and r is included in the calculation.

The following variations for calculating the message-independentcomponent may be implemented:

i) Calculate:

λ=k ⁻¹ a+β

Then the signature shares are now:

s _(i) =k _(i) ⁻¹ e−rβ _(i)

And the signature is generated as:

s=int(s ₁ , . . . , s _(t+1))+rλ

ii) Calculate:

λ=αar+β

Then the signature shares are now:

s _(i) =α _(i) e−β _(i)

And the signature is generated as:

s=(kα)⁻¹(int(s ₁, . . . , s _(t+1))+λ)

iii) Calculate:

λ=αa+β

Then the signature shares are now:

s _(i) =k _(i) ⁻¹ e−rβ _(i)

And the signature is generated as:

s=(kα)⁻¹(int(s ₁ , . . . , s _(t+1))+rλ)

iv) Calculate:

λ=αar+β

Then the signature shares are now:

s _(i) =k _(i) ⁻¹ e−(kα)⁻¹β_(i)

And the signature is generated as:

s=(int(s ₁ , . . . , s _(t+1))+(kα)⁻¹λ)

v) Calculate:

λ=αa+β

Then the signature shares are now:

s _(i) =k _(i) ⁻¹ e−r(kα)⁻¹β_(i)

And the signature is generated as:

s=(int(s ₁ , . . . , s _(t+1))+r(kα)⁻¹λ)

One difference between the method 200 and the previous schemes is thatthe calculation of the k⁻¹a term in the signature may be moved into thepre-calculation phase. The result of this is that the signaturegeneration has the same threshold as the private key calculation and sois now a threshold-optimal scheme. To see how the correct signature isfound, it is noted that the interpolation over the signature sharesresults in

s = k⁻¹e + r(k⁻¹a + β − β) = k⁻¹e + r(k⁻¹a) = k⁻¹(e + ar),

which is exactly the signature as required.

Note that the thresholds of the secrets may be different. That is thethreshold of a, k, α, β themselves do not necessarily need to be thesame to execute the signature generation scheme. For example, if thereis a group of six and three are needed to create the signature and/orprivate key, they could technically do the calculation with thethreshold of the k being four and the thresholds of the other sharedsecrets being three, and they will still have a threshold-optimalscheme.

Note that if the blinding secret β is not used, then it may be possibleto calculate the ephemeral key and therefore the shared secret key inthe following way. Assume that the participants use simply (k⁻¹a), andthat they also know r, e, and s. Anyone in the scheme can calculate

(s−(k ⁻¹ a)r)e ⁻¹ =k ⁻¹.

This result can then be used to calculate

(k ⁻¹)⁻¹(k ⁻¹ a)=a,

which is the shared private key.

By including β in the calculation, this calculation cannot be done. Thevalue (k⁻¹a+β) gives away no information about the individual secrets,nor the result k⁻¹a. In order to gain any information that would revealthe private key a, at least (t+1) participants must collaborate which isthe same number as the threshold of the private key, and so the securityis not decreased by calculating this intermediate value λ.

A problem to solve with previous threshold optimal signaturecalculations is that one must calculate the product of two sharedsecrets, where the secrets are sums of individual secrets of allparticipants in a group

${a = {\sum\limits_{i = 1}^{N}a_{i0}}},$${k = {\sum\limits_{i = 1}^{M}k_{i0}}},$

In a signature, if the private key a is a shared secret then necessarilyk must be as well (or else a can be calculated by anyone who knows k).The second term in the signature is then the multiplication of twoshared secrets and this is the part that makes it difficult to achieveoptimality. In the non-optimal scheme by Gennaro et al. and the examplemethod 200 described above, these secrets are each the zeroth order of apolynomial of order-t, and multiplying the polynomials together resultsin a threshold of 2t+1 shares required to calculate the result of themultiplication. To ensure honesty in this scheme, most communicationscan be broadcast, and simple equivalences can be checked. Additionally,if a participant drops out of the calculation of a signature, it is easyfor another participant to contribute.

In the threshold-optimal scheme by Gennaro et al., this threshold of2t+1 is avoided by calculating the individual terms in the product ofthe secrets individually. That is, each pair of participants i, jcalculate the individual terms a_(i0)k_(j0) for each i, j and summingthese results. The ephemeral key k is created during signing, and thenthese products of individual secret contributions are calculated usingPallier encryption. This requires that each participant must communicateindividually with all other signers. To ensure honesty in this case,there are multiple zero-knowledge proofs that must be executed. In thiscase, if a participant drops out of the calculation of the signature,the signature algorithm must be restarted.

In other words, each secret is the sum of individual secrets and themultiplication of two secrets is a multiplication of two sums ofindividual terms, which can be expanded out as

a ₁₀ b ₁₀ +a ₂₀ b ₁₀ +. . . b _(n0) a _(n0), etc

The Gennaro scheme calculates these terms individually. That is,participant 1 has to calculate a₂₀b10 with participant 2, and alsoa₃₀b10 with participant 3 and so on. These are then all summed together.These individual calculations involve computationally expensive zeroknowledge proofs. So as soon as there are many people in the scheme itbecomes inefficient. This is also all done at the signing phase, and soit is a computationally expensive way to calculate a signature.

In a simple case with 3 participants, the rounds of communication areroughly comparable between the two schemes (i.e. the optimal thresholdscheme by Gennaro et al. and the example method 200): while the Gennaroscheme does have more, this is not where the main efficiency savingsare. The savings are in the volume of data that is calculated andcommunicated. Gennaro's scheme has to include multiple zero-knowledgeproofs (ZKPs) which are not present in the example method 200.

The following compares a 2-of-3 scheme implemented using the optimalthreshold scheme by Gennaro et al. and the example method 200. InGennaro's scheme there is a JVRSS before signing and an additionalencryption key to create for Pallier's encryption. Then there are sevenZKPs to create, and seven ZKPs to verify in the signature calculation.These ZKPs cannot be sent simultaneously, so there are multiple roundsof communication in the signing phase. Additionally, in some steps, eachparticipant must communicate individually with all other participants inthe signing phase, which is inefficient. This means that thoseparticipants must all be online at the same time. In contrast, thepresent invention enables a given participant to calculate a signatureshare without the other participants being online.

On the other hand, in the present scheme described above, there are fourJVRSS calculations in the pre-signing phase and no ZKPs at any point.The JVRSS calculation can be done simultaneously and so thecommunication is the same as one JVRSS. In the signing phase, there isonly a request-response style communication, and all information can bebroadcast to the group.

To compare between the storage of the two schemes, note that theephemeral key is calculated with the set-up stage in the scheme above.This means that there is more storage required when compared toGennaro's scheme. For the scheme described above, there are threeadditional values to be stored corresponding to creating a signature,each with e.g. 32 bytes of storage space required. This is minimalconsidering the efficiency savings in the calculation and communication,and the optimality achievement.

To summarise, Gennaro's scheme reduces the storage required after set-upand pre-calculation but increases the calculation and communicationduring the signature calculation. This is due to it being inefficient tomove any more of the calculation to pre-signing in Gennaro's scheme. Thescheme of the present invention is more efficient than Gennaro's optimalscheme, particularly if the inequality N≥2t+1 is acceptable.

Example Use Case of Threshold Signatures

In general, the present invention can be used to generate a signature onany message. As a particular example use case, the message may be partor all of a blockchain transaction. That is, the signature may be usedto sign one or more inputs and/or one or more outputs of a blockchaintransaction.

FIG. 3 illustrates an example transaction protocol for use as part of ablockchain protocol. Example blockchain protocols are well documented inthe literature, but a description of an example protocol transaction isprovided here for completeness. This is an example of a UTXO-basedprotocol. A transaction 152 (abbreviated “Tx”) is the fundamental datastructure of the blockchain (each block of the blockchain comprising oneor more transactions 152). The following will be described by referenceto an output-based or “UTXO” based protocol. However, this not limitingto all possible embodiments.

In a UTXO-based model, each transaction (“Tx”) 152 comprises a datastructure comprising one or more inputs 202, and one or more outputs203. Each output 203 may comprise an unspent transaction output (UTXO),which can be used as the source for the input 202 of another newtransaction (if the UTXO has not already been redeemed). The UTXOincludes a value specifying an amount of a digital token, e.g.representing an amount of a digital asset. This represents a set numberof tokens on the (distributed) ledger. The UTXO may also contain thetransaction ID of the transaction from which it came, amongst otherinformation. The transaction data structure may also comprise a header201, which may comprise an indicator of the size of the input field(s)202 and output field(s) 203. The header 201 may also include an ID ofthe transaction. In embodiments the transaction ID is the hash of thetransaction data (excluding the transaction ID itself) and stored in theheader 201 of the raw transaction 152 submitted to the miners.

Say a first user, e.g. Alice, wishes to create a transaction 152 jtransferring an amount of the digital token in question to a seconduser, e.g. Bob. In FIG. 3 Alice's new transaction 152 j is labelled“Tx₁”. It takes an amount of the digital token that is locked to Alicein the output 203 of a preceding transaction 152 i in the sequence, andtransfers at least some of this to Bob. The preceding transaction 152 iis labelled “Tx₀” in FIG. 3 . Tx₀ and Tx₁ are just arbitrary labels.They do not necessarily mean that Tx₀ is the first transaction in theblockchain, nor that Tx₁ is the immediate next transaction in the pool.Tx₁ could point back to any preceding (i.e. antecedent) transaction thatstill has an unspent output 203 locked to Alice.

The preceding transaction Tx₀ may already have been validated andincluded in the blockchain at the time when Alice creates her newtransaction Tx₁, or at least by the time she sends it to the network106. It may already have been included in one of the blocks at thattime, or it may be still waiting in the pool 154 in which case it willsoon be included in a new block. Alternatively Tx₀ and Tx₁ could becreated and sent to the blockchain network together, or Tx₀ could evenbe sent after Tx₁ if the node protocol allows for buffering “orphan”transactions. The terms “preceding” and “subsequent” as used herein inthe context of the sequence of transactions refer to the order of thetransactions in the sequence as defined by the transaction pointersspecified in the transactions (which transaction points back to whichother transaction, and so forth). They could equally be replaced with“predecessor” and “successor”, or “antecedent” and “descendant”,“parent” and “child”, or such like. It does not necessarily imply anorder in which they are created, sent to the network, or arrive at anygiven node. Nevertheless, a subsequent transaction (the descendenttransaction or “child”) which points to a preceding transaction (theantecedent transaction or “parent”) will not be validated until andunless the parent transaction is validated. A child that arrives at anode before its parent is considered an orphan. It may be discarded orbuffered for a certain time to wait for the parent, depending on thenode protocol and/or miner behaviour.

One of the one or more outputs 203 of the preceding transaction Tx₀comprises a particular UTXO, labelled here UTXO₀. Each UTXO comprises avalue specifying an amount of the digital token represented by the UTXO,and a locking script which defines a condition which must be met by anunlocking script in the input 202 of a subsequent transaction in orderfor the subsequent transaction to be validated, and therefore for theUTXO to be successfully redeemed. Typically the locking script locks theamount to a particular party (the beneficiary of the transaction inwhich it is included). I.e. the locking script defines an unlockingcondition, typically comprising a condition that the unlocking script inthe input of the subsequent transaction comprises the cryptographicsignature of the party to whom the preceding transaction is locked.

The locking script (aka scriptPubKey) is a piece of code written in thedomain specific language recognized by the node protocol. A particularexample of such a language is called “Script” (capital S). The lockingscript specifies what information is required to spend a transactionoutput 203, for example the requirement of Alice's signature. Unlockingscripts appear in the outputs of transactions. The unlocking script (akascriptSig) is a piece of code written the domain specific language thatprovides the information required to satisfy the locking scriptcriteria. For example, it may contain Bob's signature. Unlocking scriptsappear in the input 202 of transactions.

So in the example illustrated, UTX₀ in the output 203 of Tx₀ comprises alocking script [Checksig P_(A)] which requires a signature Sig P_(A) ofAlice in order for UTXO₀ to be redeemed (strictly, in order for asubsequent transaction attempting to redeem UTXO₀ to be valid).[Checksig P_(A)] contains the public key P_(A) from a public-private keypair of Alice. The input 202 of Tx₁ comprises a pointer pointing back toTx₁ (e.g. by means of its transaction ID, TxID₀, which in embodiments isthe hash of the whole transaction Tx₀). The input 202 of Tx₁ comprisesan index identifying UTXO0 within Tx₀, to identify it amongst any otherpossible outputs of Tx₀. The input 202 of Tx₁ further comprises anunlocking script <Sig P_(A)> which comprises a cryptographic signatureof Alice, created by Alice applying her private key from the key pair toa predefined portion of data (sometimes called the “message” incryptography). What data (or “message”) needs to be signed by Alice toprovide a valid signature may be defined by the locking script, or bythe node protocol, or by a combination of these.

When the new transaction Tx₁ arrives at a node, the node applies thenode protocol. This comprises running the locking script and unlockingscript together to check whether the unlocking script meets thecondition defined in the locking script (where this condition maycomprise one or more criteria). In embodiments this involvesconcatenating the two scripts:

<SigP _(A) ><P _(A)>||[Checksig P _(A)]

where “||” represents a concatenation and “< . . . >” means place thedata on the stack, and “[ . . . ]” is a function comprised by theunlocking script (in this example a stack-based language). Equivalentlythe scripts may be run one after the other, with a common stack, ratherthan concatenating the scripts. Either way, when run together, thescripts use the public key P_(A) of Alice, as included in the lockingscript in the output of Tx₀, to authenticate that the locking script inthe input of Tx₁ contains the signature of Alice signing the expectedportion of data. The expected portion of data itself (the “message”)also needs to be included in Tx₀ in order to perform thisauthentication. In embodiments the signed data comprises the whole ofTx₀ (so a separate element does to need to be included specifying thesigned portion of data in the clear, as it is already inherentlypresent).

The details of authentication by public-private cryptography will befamiliar to a person skilled in the art. Basically, if Alice has signeda message by encrypting it with her private key, then given Alice'spublic key and the message in the clear (the unencrypted message),another entity such as a node of the blockchain network is able toauthenticate that the encrypted version of the message must have beensigned by Alice. Signing typically comprises hashing the message,signing the hash, and tagging this onto the clear version of the messageas a signature, thus enabling any holder of the public key toauthenticate the signature. Note therefore that any reference herein tosigning a particular piece of data or part of a transaction, or suchlike, can in embodiments mean signing a hash of that piece of data orpart of the transaction.

If the unlocking script in Tx₁ meets the one or more conditionsspecified in the locking script of Tx₀ (so in the example shown, ifAlice's signature is provided in Tx₁ and authenticated), then theblockchain node deems Tx₁ valid. If it is a mining node, this means itwill add it to the pool of transactions awaiting proof-of-work. If it isa forwarding node, it will forward the transaction Tx₁ to one or moreother nodes in the blockchain network, so that it will be propagatedthroughout the network. Once Tx₁ has been validated and included in theblockchain, this defines UTXO₀ from Tx₀ as spent. Note that Tx₁ can onlybe valid if it spends an unspent transaction output 203. If it attemptsto spend an output that has already been spent by another transaction,then Tx₁ will be invalid even if all the other conditions are met. Hencethe node 104 also needs to check whether the referenced UTXO in thepreceding transaction Tx₀ is already spent (has already formed a validinput to another valid transaction). This is one reason why it isimportant for the blockchain 150 to impose a defined order on thetransactions. In practice a given node 104 may maintain a separatedatabase marking which UTXOs 203 in which transactions have been spent,but ultimately what defines whether a UTXO has been spent is whether ithas already formed a valid input to another valid transaction in theblockchain.

If the total amount specified in all the outputs 203 of a giventransaction is greater than the total amount pointed to by all itsinputs 202, this is another basis for invalidity in most transactionmodels. Therefore such transactions will not be propagated nor minedinto blocks.

Note that the script code is often represented schematically (i.e. notthe exact language). For example, one may write [Checksig P_(A)] to mean[Checksig P_(A)]=OP_DUP OP_HASH160 <H(P_(A))>OP_EQUALVERIFY OP_CHECKSIG.“OP_ . . . ” refers to a particular opcode of the Script language.OP_CHECKSIG (also called “Checksig”) is a Script opcode that takes twoinputs (signature and public key) and verifies the signature's validityusing the Elliptic Curve Digital Signature Algorithm (ECDSA). Atruntime, any occurrences of signature (‘sig’) are removed from thescript but additional requirements, such as a hash puzzle, remain in thetransaction verified by the ‘sig’ input. As another example, OP_RETURNis an opcode of the Script language for creating an unspendable outputof a transaction that can store metadata within the transaction, andthereby record the metadata immutably in the blockchain. E.g. themetadata could comprise a document which it is desired to store in theblockchain.

The signature P_(A) is a digital signature. In embodiments this is basedon the ECDSA using the elliptic curve secp256k1. A digital signaturesigns a particular piece of data. In embodiments, for a giventransaction the signature will sign part of the transaction input, andall or part of the transaction output. The particular parts of theoutputs it signs depends on the SIGHASH flag. The SIGHASH flag is a4-byte code included at the end of a signature to select which outputsare signed (and thus fixed at the time of signing).

The locking script is sometimes called “scriptPubKey” referring to thefact that it comprises the public key of the party to whom therespective transaction is locked. The unlocking script is sometimescalled “scriptSig” referring to the fact that it supplies thecorresponding signature. However, more generally it is not essential inall applications of a blockchain that the condition for a UTXO to beredeemed comprises authenticating a signature. More generally thescripting language could be used to define any one or more conditions.Hence the more general terms “locking script” and “unlocking script” maybe preferred.

According to some embodiments of the present invention, the signaturegenerated by the coordinator 101 may be used to sign a blockchaintransaction. For instance, the generated signature may be used, at leastin part, to unlock an output of a blockchain transaction. As aparticular example, the output of a previous transaction may be apay-to-public-key-hash (P2PKH) output which is locked to a hash of apublic key. In order to be unlocked, an input of a later transactionthat references the P2PKH output needs to include the (unhashed) publickey and a signature generated based on the private key corresponding tothe public key.

Represented in script, the “locking script” and “unlocking script” maytake the following forms:

Locking script=OP_DUP OP_HASH160<Public KeyHash>OP_EQUAL OP_CHECKSIGUnlocking script=<Signature><Public Key>

Referring to the above described embodiments, the <Public Key> may beequated to P=a·G, and the <Signature> comprises the threshold signatures, where the previous transaction is the message to be signed. Note thatas stated above, ECDSA signatures are in the form (r, s).

Note that the described signature generation method is not limited toany particular use case and may in general be used for generating asignature based on any message. Signing all or part of a blockchaintransaction is just one illustrative example. The described method maybe used to sign and/or authorise, for instance, a legal document (e.g. awill, deed or other contract), correspondence between one or moreparties, digital certificates (e.g. issued by a certificate authority),medical prescriptions, a bank transfer or a financial instrument, amortgage or loan applications, etc.

As a particular example, the group of participants (say fiveparticipants in total) may form the Board of a company. Voting mattersof the company may require a majority of the Board (i.e. at least threeparticipants) to agree on the particular vote. The Board may use thedescribed signature generation method to prove that at least three Boardmembers agreed to vote in favour of a particular outcome. In thisexample, the threshold of the signature generation scheme is three. Thatis, at least three of the Board members must provide a respectivesignature share in order for the co-ordinator to successfully generate asignature. If a signature is generated successfully, at least thethreshold number (i.e. three) of Board members must have agreed to votein favour of that outcome. Thus the successful generation of a signatureacts as a record of the vote and proves that a majority of the Boardvoted in a particular way.

Another use case for the present invention lays in the field of digitalcertificates, e.g. digital certificate issued by the X.509 standard. Adigital certificate contains a signature that signs over some data. Thedata can in general be any data, but one particular example of dataincluded in a digital certificate is a public key. A public key in adigital certificate is often referred to as a “certified public key”.The issuer of the digital certificate (a “certificate authority”) mayperform one or more checks on the owner of the public key (e.g.know-your-customer checks), and if the checks are successful, thecertificate authority issues a digital certificate that includes thecertified public key. A user can use a certified public key to provethey are who they say they are, e.g. by signing a message with a privatekey corresponding to the certified public key.

One particular use for certificate authorities is to sign certificatesused in HTTPS for secure browsing on the internet. Another common use isin issuing identity cards by national governments for use inelectronically signing documents. The certificate authority signs thepublic key (or any other data to be attested to) using a private key.This introduces a single point of failure. That is, if a malicious partycan gain access to the private key used by the certificate authority toissue digital certificates, the malicious party can then issuefraudulent certificates. A particular example of a certificate authoritybeing targeted is DigiNotar, a Dutch certificate authority. The privatekey used by DigiNotar was compromised in 2011 and used to issuefraudulent certificates. This attack was possible as the attacker neededonly to obtain a single piece of data, i.e. the private key. However,this attack would not have been possible (or at least made moredifficult) if the certificate authority (DigiNotar) used a thresholdsignature scheme according to the present invention. In order to issuecertificates, an attacker must acquire the threshold number of keyshares (or signature shares) required for generating the signature.

It will be appreciated that the above embodiments have been described byway of example only. More generally there may be provided a method,apparatus or program in accordance with any one or more of the followingStatements.

Statement 1. A computer-implemented method of identifying adenial-of-service attack during a threshold signature scheme, whereineach participant of a group of participants has a respective share of afirst shared secret and a respective share of a second shared secret,wherein the method is performed by a first participant of the group andcomprises: calculating a first target share based on at least a firstshare of the first shared secret and a first share of the second sharedsecret, wherein the first target share is used to calculate a firstsignature share of a threshold signature; calculating a target valuebased on the first target share and a first predetermined amount ofother target shares, wherein each other target share is calculated by arespective participant; calculating a target public key corresponding tothe target value; calculating a first verification share based on thefirst share of the first shared secret and a public key corresponding tothe second shared secret; calculating a verification public key based onat least the first verification share and a second predetermined amountof other verification shares, wherein each other verification share iscalculated by a respective participant; and determining whether at leastone other participant is attempting a denial-of-service attack based onwhether the verification public key matches the target public key.

A threshold number of different signature shares from respectiveparticipants of a group of participants are required to generate thedigital signature.

The target value may be calculated by interpolating over the firsttarget share and the first predetermined amount of other target shares.The verification public key may be calculated by performing ellipticcurve interpolation over the first verification share and the secondpredetermined amount of other verification shares.

Statement 2. The method of statement 1, comprising sharing the firsttarget share and the first verification share with the otherparticipants in the group.

Statement 3. The method of statement 2, wherein said sharing comprisesbroadcasting the first target share and/or the first verification shareto the other participants in the group.

Alternatively, the first target share and/or the first verificationshare may be transmitted directly to each other participant, e.g. overrespective secure communication channels.

Statement 4. The method of any preceding statement, comprising:obtaining the first predetermined amount of other target shares from therespective participants; and obtaining the second predetermined amountof other verification shares from the respective participants.

Statement 5. The method of any preceding statement, wherein the firstshare of the first shared secret is calculated by performing a firstinstance of a joint verification random secret sharing scheme (JVRSS)with the group of participants.

Statement 6. The method of any preceding statement, wherein the firstshare of the second shared secret is calculated by performing a secondinstance of JVRSS with the group of participants.

Statement 7. The method of statement 6, wherein the public keycorresponding to the second shared secret is calculated based on theobfuscated coefficients shared by each participant when performing thesecond instance of JVRSS.

Statement 8. The method of any preceding statement, wherein eachparticipant is associated with a respective index of a sequence, whereinthe first predetermined amount of other target shares are calculated bythose other participants with respective indices following the index ofthe first participant, and wherein the second predetermined amount ofother verification shares are calculated by those other participantswith respective indices following the index of the first participant.

Statement 9. The method of any preceding statement, wherein the grouphas a size N≥2t+1 wherein the threshold of the first shared secret andof the threshold signature is t+1, and wherein t is the degree of thefirst shared secret. Here, t is the degree of the shared secretpolynomial.

In some examples, the first and second shared secrets may have differentthresholds. In some examples, the first shared secret and the thresholdsignature may have different thresholds. For instance, the threshold ofthe threshold signature may be greater than that of the first sharedsecret. E.g. the threshold of the signature may be t+2 and the thresholdof the first shared secret may be t+1.

Statement 10. The method of statement 9, wherein the first predeterminedamount is 2t and wherein the second predetermined amount is t.

Statement 11. The method of statement 9 or statement 10, wherein thegroup has a size N>2t+1, wherein said calculating of the verificationpublic key comprises calculating a plurality of verification publickeys, each verification public key being calculated based on the firstverification share and a different second predetermined amount of otherverification shares, and wherein the method comprises: comparing each ofthe plurality of verification public keys; and identifying at least oneparticipant attempting a denial-of-service attack as the participantwhose respective verification share results in a verification public keythat does not match at least one other verification public key.

Statement 12. The method of any preceding statement, wherein the firstshared secret is a first blinding key, wherein the second shared secretis an ephemeral key, and wherein the first target share is amultiplicative share.

Statement 13. The method of any of statements 1 to 11, wherein eachparticipant of the group of participants has a respective share of athird shared secret, wherein the first target share is calculated basedon a first share of the first shared secret, and wherein theverification public key is calculated based on a public keycorresponding to the third shared secret.

Statement 14. The method of statement 13, wherein the first sharedsecret is an inverse ephemeral key, the second shared secret is aprivate key, the third shared secret is a second blinding key, and thefirst target share is a first intermediary share.

Statement 15. The method of statement 13 or statement 14, wherein thefirst share of the third shared secret is calculated by performing athird instance of JVRSS with the group of participants.

Statement 16. The method of statement 6, wherein the public keycorresponding to the third shared secret is calculated based on theobfuscated coefficients shared by each participant when performing thethird instance of JVRSS.

Statement 17. The method of any preceding statement, comprising onlyusing the first target share and/or the target value to calculate thefirst signature share on condition that the verification public keymatches the target public key.

For instance, the multiplicative share may be used to calculate aninverse ephemeral key share.

Statement 18. Computer equipment comprising: memory comprising one ormore memory units; and processing apparatus comprising one or moreprocessing units, wherein the memory stores code arranged to run on theprocessing apparatus, the code being configured so as when on theprocessing apparatus to perform the method of any of statements 1 to 17.

Statement 19. A computer program embodied on computer-readable storageand configured so as, when run on computer equipment to perform themethod of any of statements 1 to 17.

Statement 20. A computer-implemented method of identifying adenial-of-service attack during a threshold signature scheme, whereineach participant of a group of participants has a respective share of ashared private key, a respective share of an ephemeral private key, arespective share of a first blinding key, and a respective share of asecond blinding key, wherein the method is performed by a firstparticipant of the group and comprises: calculating a first public keycorresponding to a first inverse ephemeral private key share, whereinfirst public key is calculated based on i) an inverse of a product ofthe ephemeral private key and the first blinding key, and ii) a publickey corresponding to a first share of the first blinding key;calculating a second public key corresponding to a pre-signature share,wherein the second public key is calculated based on i) a public keycorresponding to an intermediary value and ii) a public keycorresponding to a first share of the second blinding key, wherein theintermediary value is based on i) an inverse of the ephemeral privatekey, ii) the private key and iii) the second blinding key; and sendingthe first public key and the second public key to a coordinating party,wherein the coordinating party has access to a first signature sharecalculated by the first participant, and wherein the first signatureshare is calculated based on i) a first share of the ephemeral privatekey, ii) a message, iii) a public key corresponding to the sharedprivate key, and iv) a first share of the second blinding key.

Statement 21. The method of statement 20, wherein some or all of therespective shares are calculated using respective instances of a jointverifiable random secret sharing (JVRSS) scheme.

Statement 22. The method of statement 21 or statement 22, comprisingcalculating the inverse of the product of the ephemeral private key andthe first blinding key.

Statement 23. The method of any preceding statement, comprisingcalculating the intermediary value based on a first intermediary shareand a respective intermediary share from each other participant.

Statement 24. The method of statement 23, comprising calculating thepublic key corresponding to the intermediary value.

Statement 25. The method of any preceding statement, comprisingcalculating the public key corresponding to the first share of the firstblinding key.

Statement 26. The method of any preceding statement, comprisingcalculating the public key corresponding to the first share of thesecond blinding key.

Statement 27. The method of any preceding statement, comprising:calculating the first signature share; and sending the first signatureshare to the coordinating party

Statement 28. The method of any preceding statement, comprisingobtaining the message from the coordinating party.

Statement 29. The method of any of statements 20 to 28, comprisinggenerating the message.

Statement 30. The method of any preceding statement, comprisingcalculating the public key corresponding to the shared ephemeral privatekey, and wherein the first signature share is based on a firstcoordinate of the public key corresponding to the shared ephemeralprivate key. E.g. the x-coordinate.

Statement 31. A computer-implemented method of identifying adenial-of-service attack, wherein each participant of a group ofparticipants has a respective share of a private key, a respective shareof an ephemeral private key, a respective share of a first blinding key,and a respective share of a second blinding key, and wherein the methodis performed by a coordinating party configured to generate a signaturebased on a threshold number of signature shares, and comprises:receiving a first public key from a first participant; receiving asecond public key from the first participant; receiving a firstsignature share from the first participant; calculating a public keycorresponding to a first candidate signature share based on i) the firstpublic key, ii) a message, iii) a public key corresponding to the sharedephemeral private key, and iv) the second public key; and determiningwhether the first participant is attempting a denial-of-service attackbased on whether a public key corresponding to the first signature sharematches the public key corresponding to the first candidate signatureshare.

E.g. the public key corresponding to the candidate first signature shareis generated by obfuscating the candidate first signature share with thegenerator point G.

Statement 32. A computer-implemented method of identifying adenial-of-service attack, wherein each participant of a group ofparticipants has a respective share of a private key, a respective shareof an ephemeral private key, a respective share of a first blinding key,and a respective share of a second blinding key, and wherein the methodis performed by a coordinating party configured to generate a signaturebased on a threshold number of signature shares, and comprises:calculating a first public key corresponding to a first inverseephemeral private key share of a first participant; calculating a secondpublic key corresponding to a pre-signature share of the firstparticipant; receiving a first signature share from the firstparticipant; calculating a public key corresponding to a candidate firstsignature share based on i) the first public key, ii) a message, iii) apublic key corresponding to the shared ephemeral private key, and iv)the second public key; and determining whether the first participant isattempting a denial-of-service attack based on whether a public keycorresponding to the first signature share matches the public keycorresponding to the candidate first signature share.

The coordinator may calculate a respective first public key andrespective second public key for some or all of the other participants.This allows the coordinator to determine whether those otherparticipants are attempting a denial-of-service attack.

The coordinating party may be a participant of the group.

Statement 33. The method of statement 31 or statement 32, comprising, oncondition that the public key corresponding to the first signaturematches the public key corresponding to the candidate first signatureshare, using the first signature share to calculate a signature based onthe first signature and one or more additional signature sharescalculated by respective participants of the group.

Statement 34. The method of statement 33, comprising: using the firstsignature share to calculate a signature based on the first signatureshare and one or more additional signature shares calculated byrespective participant of the group, wherein the first signature shareis received prior to said receiving or calculating of the first publickey and the second public key; determining whether the signature is aninvalid signature; and performing said determining of whether the firstparticipant is attempting a denial-of-service attack in response todetermining that the signature is an invalid signature.

Statement 35. The method of statement 34, wherein said determining ofwhether the signature is an invalid signature comprises verifying thesignature against the public key corresponding to the shared privatekey.

Statement 36. Computer equipment comprising: memory comprising one ormore memory units; and processing apparatus comprising one or moreprocessing units, wherein the memory stores code arranged to run on theprocessing apparatus, the code being configured so as when on theprocessing apparatus to perform the method of any of statements 20 to35.

Statement 37. A computer program embodied on computer-readable storageand configured so as, when run on computer equipment to perform themethod of any of statements 20 to 35.

According to another aspect disclosed herein, there may be provided amethod comprising the actions of some or all of: the first participant,some or all of the other participants, and the coordinator.

According to another aspect disclosed herein, there may be provided asystem comprising the computer equipment some or all of: the firstparticipant, some or all of the other participants, and the coordinator.

Other variants or use cases of the disclosed techniques may becomeapparent to the person skilled in the art once given the disclosureherein. The scope of the disclosure is not limited by the describedembodiments but only by the accompanying claims.

1. A computer-implemented method of identifying a denial-of-serviceattack during a threshold signature scheme, wherein each participant ofa group of participants has a respective share of a first shared secretand a respective share of a second shared secret, wherein the method isperformed by a first participant of the group and comprises: calculatinga first target share based on at least a first share of the first sharedsecret and a first share of the second shared secret, wherein the firsttarget share is used to calculate a first signature share of a thresholdsignature; calculating a target value based on the first target shareand a first predetermined amount of other target shares, wherein eachother target share is calculated by a respective participant;calculating a target public key corresponding to the target value;calculating a first verification share based on the first share of thefirst shared secret and a public key corresponding to the second sharedsecret; calculating a verification public key based on at least thefirst verification share and a second predetermined amount of otherverification shares, wherein each other verification share is calculatedby a respective participant; and determining whether at least one otherparticipant is attempting a denial-of-service attack based on whetherthe verification public key matches the target public key.
 2. The methodof claim 1, comprising sharing the first target share and the firstverification share with the other participants in the group.
 3. Themethod of claim 2, wherein said sharing comprises broadcasting the firsttarget share and/or the first verification share to the otherparticipants in the group.
 4. The method of claim 1, comprising:obtaining the first predetermined amount of other target shares from therespective participants; and obtaining the second predetermined amountof other verification shares from the respective participants.
 5. Themethod of claim 1, wherein the first share of the first shared secret iscalculated by performing a first instance of a joint verification randomsecret sharing scheme (JVRSS) with the group of participants.
 6. Themethod of claim 1, wherein the first share of the second shared secretis calculated by performing a second instance of JVRSS with the group ofparticipants.
 7. The method of claim 6, wherein the public keycorresponding to the second shared secret is calculated based onobfuscated coefficients shared by each participant when performing thesecond instance of JVRSS.
 8. The method of claim 1, wherein eachparticipant is associated with a respective index of a sequence, whereinthe first predetermined amount of other target shares are calculated bythose other participants with respective indices following the index ofthe first participant, and wherein the second predetermined amount ofother verification shares are calculated by those other participantswith respective indices following the index of the first participant. 9.The method of claim 1, wherein the group has a size N≥2t+1 wherein thethreshold of the first shared secret and of the threshold signature ist+1, and wherein t is the degree of the first shared secret.
 10. Themethod of claim 9, wherein the first predetermined amount is 2t andwherein the second predetermined amount is t.
 11. The method of claim 9,wherein the group has a size N>2t+1, wherein said calculating of theverification public key comprises calculating a plurality ofverification public keys, each verification public key being calculatedbased on the first verification share and a different secondpredetermined amount of other verification shares, and wherein themethod comprises: comparing each of the plurality of verification publickeys; and identifying at least one participant attempting adenial-of-service attack as the participant whose respectiveverification share results in a verification public key that does notmatch at least one other verification public key.
 12. The method ofclaim 1, wherein the first shared secret is a first blinding key,wherein the second shared secret is an ephemeral key, and wherein thefirst target share is a multiplicative share.
 13. The method of any ofclaim 1, wherein each participant of the group of participants has arespective share of a third shared secret, wherein the first targetshare is calculated based on a first share of the first shared secret,and wherein the verification public key is calculated based on a publickey corresponding to the third shared secret.
 14. The method of claim13, wherein the first shared secret is an inverse ephemeral key, thesecond shared secret is a private key, the third shared secret is asecond blinding key, and the first target share is a first intermediaryshare.
 15. The method of claim 13, wherein the first share of the thirdshared secret is calculated by performing a third instance of JVRSS withthe group of participants.
 16. The method of claim 15, wherein thepublic key corresponding to the third shared secret is calculated basedon obfuscated coefficients shared by each participant when performingthe third instance of JVRSS.
 17. The method of claim 1, comprising onlyusing the first target share and/or the target value to calculate thefirst signature share on condition that the verification public keymatches the target public key.
 18. Computer equipment comprising: memorycomprising one or more memory units; and processing apparatus comprisingone or more processing units, wherein the memory stores code arranged torun on the processing apparatus, the code being configured so as whenrun on the processing apparatus, the processing apparatus performs amethod of identifying a denial-of-service attack during a thresholdsignature scheme, wherein each participant of a group of participantshas a respective share of a first shared secret and a respective shareof a second shared secret, wherein the method is performed by a firstparticipant of the group and comprises: calculating a first target sharebased on at least a first share of the first shared secret and a firstshare of the second shared secret, wherein the first target share isused to calculate a first signature share of a threshold signature;calculating a target value based on the first target share and a firstpredetermined amount of other target shares, wherein each other targetshare is calculated by a respective participant; calculating a targetpublic key corresponding to the target value; calculating a firstverification share based on the first share of the first shared secretand a public key corresponding to the second shared secret; calculatinga verification public key based on at least the first verification shareand a second predetermined amount of other verification shares, whereineach other verification share is calculated by a respective participant;and determining whether at least one other participant is attempting adenial-of-service attack based on whether the verification public keymatches the target public key.
 19. A computer program embodied onnon-transitory computer-readable storage media and configured so as,when run on computer equipment, the computer equipment performs a methodof identifying a denial-of-service attack during a threshold signaturescheme, wherein each participant of a group of participants has arespective share of a first shared secret and a respective share of asecond shared secret, wherein the method is performed by a firstparticipant of the group and comprises: calculating a first target sharebased on at least a first share of the first shared secret and a firstshare of the second shared secret, wherein the first target share isused to calculate a first signature share of a threshold signature;calculating a target value based on the first target share and a firstpredetermined amount of other target shares, wherein each other targetshare is calculated by a respective participant; calculating a targetpublic key corresponding to the target value; calculating a firstverification share based on the first share of the first shared secretand a public key corresponding to the second shared secret; calculatinga verification public key based on at least the first verification shareand a second predetermined amount of other verification shares, whereineach other verification share is calculated by a respective participant;and determining whether at least one other participant is attempting adenial-of-service attack based on whether the verification public keymatches the target public key. 20-37. (canceled)